* [PATCH v4 5/9] clk: sunxi-ng: Implement minimum for multipliers
From: Maxime Ripard @ 2016-10-20 17:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v67Mo41RHiWd=9+ggcDDmWJ2Miyo17Nni3p3mmAzoJng3w@mail.gmail.com>
On Thu, Oct 20, 2016 at 11:06:21PM +0800, Chen-Yu Tsai wrote:
> On Tue, Oct 11, 2016 at 10:28 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > Allow the CCU drivers to specify a multiplier for their clocks.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > ---
> > drivers/clk/sunxi-ng/ccu_mult.c | 2 +-
> > drivers/clk/sunxi-ng/ccu_mult.h | 13 +++++++++----
> > drivers/clk/sunxi-ng/ccu_nk.c | 8 ++++----
> > drivers/clk/sunxi-ng/ccu_nkm.c | 8 ++++----
> > drivers/clk/sunxi-ng/ccu_nkmp.c | 4 ++--
> > drivers/clk/sunxi-ng/ccu_nm.c | 2 +-
> > 6 files changed, 21 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/clk/sunxi-ng/ccu_mult.c b/drivers/clk/sunxi-ng/ccu_mult.c
> > index 6a02ffee5386..678b6cb49f01 100644
> > --- a/drivers/clk/sunxi-ng/ccu_mult.c
> > +++ b/drivers/clk/sunxi-ng/ccu_mult.c
> > @@ -105,7 +105,7 @@ static int ccu_mult_set_rate(struct clk_hw *hw, unsigned long rate,
> > ccu_mux_helper_adjust_parent_for_prediv(&cm->common, &cm->mux, -1,
> > &parent_rate);
> >
> > - _cm.min = 1;
> > + _cm.min = cm->mult.min;
> > _cm.max = 1 << cm->mult.width;
> > ccu_mult_find_best(parent_rate, rate, &_cm);
> >
> > diff --git a/drivers/clk/sunxi-ng/ccu_mult.h b/drivers/clk/sunxi-ng/ccu_mult.h
> > index 113780b7558e..c1a2134bdc71 100644
> > --- a/drivers/clk/sunxi-ng/ccu_mult.h
> > +++ b/drivers/clk/sunxi-ng/ccu_mult.h
> > @@ -7,14 +7,19 @@
> > struct ccu_mult_internal {
> > u8 shift;
> > u8 width;
> > + u8 min;
> > };
> >
> > -#define _SUNXI_CCU_MULT(_shift, _width) \
> > - { \
> > - .shift = _shift, \
> > - .width = _width, \
> > +#define _SUNXI_CCU_MULT_MIN(_shift, _width, _min) \
> > + { \
> > + .shift = _shift, \
> > + .width = _width, \
> > + .min = _min, \
> > }
> >
> > +#define _SUNXI_CCU_MULT(_shift, _width) \
> > + _SUNXI_CCU_MULT_MIN(_shift, _width, 1)
> > +
> > struct ccu_mult {
> > u32 enable;
> >
> > diff --git a/drivers/clk/sunxi-ng/ccu_nk.c b/drivers/clk/sunxi-ng/ccu_nk.c
> > index a42d870ba0ef..eaf0fdf78d2b 100644
> > --- a/drivers/clk/sunxi-ng/ccu_nk.c
> > +++ b/drivers/clk/sunxi-ng/ccu_nk.c
> > @@ -97,9 +97,9 @@ static long ccu_nk_round_rate(struct clk_hw *hw, unsigned long rate,
> > if (nk->common.features & CCU_FEATURE_FIXED_POSTDIV)
> > rate *= nk->fixed_post_div;
> >
> > - _nk.min_n = 1;
> > + _nk.min_n = nk->n.min;
> > _nk.max_n = 1 << nk->n.width;
> > - _nk.min_k = 1;
> > + _nk.min_k = nk->k.min;
> > _nk.max_k = 1 << nk->k.width;
> >
> > ccu_nk_find_best(*parent_rate, rate, &_nk);
> > @@ -122,9 +122,9 @@ static int ccu_nk_set_rate(struct clk_hw *hw, unsigned long rate,
> > if (nk->common.features & CCU_FEATURE_FIXED_POSTDIV)
> > rate = rate * nk->fixed_post_div;
> >
> > - _nk.min_n = 1;
> > + _nk.min_n = nk->n.min;
> > _nk.max_n = 1 << nk->n.width;
> > - _nk.min_k = 1;
> > + _nk.min_k = nk->k.min;
> > _nk.max_k = 1 << nk->k.width;
> >
> > ccu_nk_find_best(parent_rate, rate, &_nk);
> > diff --git a/drivers/clk/sunxi-ng/ccu_nkm.c b/drivers/clk/sunxi-ng/ccu_nkm.c
> > index b2a5fccf2f8c..715b49211ddb 100644
> > --- a/drivers/clk/sunxi-ng/ccu_nkm.c
> > +++ b/drivers/clk/sunxi-ng/ccu_nkm.c
> > @@ -100,9 +100,9 @@ static unsigned long ccu_nkm_round_rate(struct ccu_mux_internal *mux,
> > struct ccu_nkm *nkm = data;
> > struct _ccu_nkm _nkm;
> >
> > - _nkm.min_n = 1;
> > + _nkm.min_n = nkm->n.min;
> > _nkm.max_n = 1 << nkm->n.width;
> > - _nkm.min_k = 1;
> > + _nkm.min_n = nkm->k.min;
>
> Typo here.
>
> > _nkm.max_k = 1 << nkm->k.width;
> > _nkm.min_m = 1;
> > _nkm.max_m = nkm->m.max ?: 1 << nkm->m.width;
> > @@ -129,9 +129,9 @@ static int ccu_nkm_set_rate(struct clk_hw *hw, unsigned long rate,
> > unsigned long flags;
> > u32 reg;
> >
> > - _nkm.min_n = 1;
> > + _nkm.min_n = nkm->n.min;
> > _nkm.max_n = 1 << nkm->n.width;
> > - _nkm.min_k = 1;
> > + _nkm.min_n = nkm->k.min;
>
> And here.
>
> > _nkm.max_k = 1 << nkm->k.width;
> > _nkm.min_m = 1;
> > _nkm.max_m = nkm->m.max ?: 1 << nkm->m.width;
> > diff --git a/drivers/clk/sunxi-ng/ccu_nkmp.c b/drivers/clk/sunxi-ng/ccu_nkmp.c
> > index 2c1398192e48..7968e0bac5db 100644
> > --- a/drivers/clk/sunxi-ng/ccu_nkmp.c
> > +++ b/drivers/clk/sunxi-ng/ccu_nkmp.c
> > @@ -107,9 +107,9 @@ static long ccu_nkmp_round_rate(struct clk_hw *hw, unsigned long rate,
> > struct ccu_nkmp *nkmp = hw_to_ccu_nkmp(hw);
> > struct _ccu_nkmp _nkmp;
> >
> > - _nkmp.min_n = 1;
> > + _nkmp.min_n = nkmp->n.min;
> > _nkmp.max_n = 1 << nkmp->n.width;
> > - _nkmp.min_k = 1;
> > + _nkmp.min_n = nkmp->k.min;
>
> And here.
>
> > _nkmp.max_k = 1 << nkmp->k.width;
> > _nkmp.min_m = 1;
> > _nkmp.max_m = nkmp->m.max ?: 1 << nkmp->m.width;
> > diff --git a/drivers/clk/sunxi-ng/ccu_nm.c b/drivers/clk/sunxi-ng/ccu_nm.c
> > index 2a190bc032a9..b1f3f0e8899d 100644
> > --- a/drivers/clk/sunxi-ng/ccu_nm.c
> > +++ b/drivers/clk/sunxi-ng/ccu_nm.c
> > @@ -93,7 +93,7 @@ static long ccu_nm_round_rate(struct clk_hw *hw, unsigned long rate,
> > struct ccu_nm *nm = hw_to_ccu_nm(hw);
> > struct _ccu_nm _nm;
> >
> > - _nm.min_n = 1;
> > + _nm.min_n = nm->n.min;
> > _nm.max_n = 1 << nm->n.width;
> > _nm.min_m = 1;
> > _nm.max_m = nm->m.max ?: 1 << nm->m.width;
> > --
> > git-series 0.8.10
>
> Otherwise,
>
> Acked-by: Chen-Yu Tsai <wens@csie.org>
Fixed and applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161020/f586f2e1/attachment.sig>
^ permalink raw reply
* [PATCH] ARM: imx: gpc: Initialize all power domains
From: Fabio Estevam @ 2016-10-20 17:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161019141556.GA18806@tiger>
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.
^ permalink raw reply related
* [PATCH v4 4/9] clk: sunxi-ng: Add minimums for all the relevant structures and clocks
From: Maxime Ripard @ 2016-10-20 17:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v64itwTvMoxvtYDqOALL-XJYvhv-5daPPjPzb9DfY3o62A@mail.gmail.com>
On Thu, Oct 20, 2016 at 11:04:18PM +0800, Chen-Yu Tsai wrote:
> On Tue, Oct 11, 2016 at 10:28 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > Modify the current clocks we have to be able to specify the minimum for
> > each clocks we support, just like we support the max.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>
> Acked-by: Chen-Yu Tsai <wens@csie.org>
>
> Including the bits from patch 2.
Applied with those bits merged in this patch.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161020/f33ffa13/attachment.sig>
^ permalink raw reply
* [PATCH v4 3/9] clk: sunxi-ng: Finish to convert to structures for arguments
From: Maxime Ripard @ 2016-10-20 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v67CWEEcC+AQ9MqsyKokTx2ZVXKqBSUFW_x7CfjHrL_JFA@mail.gmail.com>
On Thu, Oct 20, 2016 at 10:35:18PM +0800, Chen-Yu Tsai wrote:
> On Tue, Oct 11, 2016 at 10:28 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > Some clocks still use an explicit list of arguments, which make it a bit
> > more tedious to add new parameters.
> >
> > Convert those over to a structure pointer argument to add as many
> > arguments as possible without having to many noise in our patches, or a
> > very long list of arguments.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>
> Acked-by: Chen-Yu Tsai <wens@csie.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161020/de349263/attachment.sig>
^ permalink raw reply
* [PATCH v4 2/9] clk: sunxi-ng: Remove the use of rational computations
From: Maxime Ripard @ 2016-10-20 17:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v65=xM3HpV05zt+q2vshX49MGkB88s7cfpwVYASodK11Nw@mail.gmail.com>
On Thu, Oct 20, 2016 at 10:30:36PM +0800, Chen-Yu Tsai wrote:
> On Tue, Oct 11, 2016 at 10:28 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > While the rational library works great, it doesn't really allow us to add
> > more constraints, like the minimum.
> >
> > Remove that in order to be able to deal with the constraints we'll need.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > ---
> > drivers/clk/sunxi-ng/Kconfig | 3 +--
> > drivers/clk/sunxi-ng/ccu_nkm.c | 31 +++++++++-----------
> > drivers/clk/sunxi-ng/ccu_nkmp.c | 45 +++++++++++++---------------
> > drivers/clk/sunxi-ng/ccu_nm.c | 54 +++++++++++++++++++++++++---------
> > 4 files changed, 78 insertions(+), 55 deletions(-)
> >
>
> [...]
>
> > diff --git a/drivers/clk/sunxi-ng/ccu_nkmp.c b/drivers/clk/sunxi-ng/ccu_nkmp.c
> > index 9769dee99511..4b457d8cce11 100644
> > --- a/drivers/clk/sunxi-ng/ccu_nkmp.c
> > +++ b/drivers/clk/sunxi-ng/ccu_nkmp.c
> > @@ -9,16 +9,15 @@
> > */
> >
> > #include <linux/clk-provider.h>
> > -#include <linux/rational.h>
> >
> > #include "ccu_gate.h"
> > #include "ccu_nkmp.h"
> >
> > struct _ccu_nkmp {
> > - unsigned long n, max_n;
> > - unsigned long k, max_k;
> > - unsigned long m, max_m;
> > - unsigned long p, max_p;
> > + unsigned long n, min_n, max_n;
> > + unsigned long k, min_k, max_k;
> > + unsigned long m, min_m, max_m;
> > + unsigned long p, min_p, max_p;
>
> Wrong patch? Otherwise,
>
> Acked-by: Chen-Yu Tsai <wens@csie.org>
Indeed, fixed and applied.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161020/738a756b/attachment-0001.sig>
^ permalink raw reply
* [linux-sunxi] [PATCH v4 1/9] clk: sunxi-ng: Rename the internal structures
From: Maxime Ripard @ 2016-10-20 17:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v65VpRU8pp_Y4RtquSj-gdJbf5S2jK5HqHKF3RnZEODmMg@mail.gmail.com>
On Thu, Oct 20, 2016 at 10:27:48PM +0800, Chen-Yu Tsai wrote:
> On Tue, Oct 11, 2016 at 10:28 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > Rename the structures meant to be embedded in other structures to make it
> > consistent with the mux structure name
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>
> Acked-by: Chen-Yu Tsai <wens@csie.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161020/65fb8838/attachment.sig>
^ permalink raw reply
* [GIT PULL] arm64: fixes for -rc2
From: Will Deacon @ 2016-10-20 17:14 UTC (permalink / raw)
To: linux-arm-kernel
Hi Linus,
Please pull these arm64 fixes for -rc2. Most of these are CC'd for
stable, but there are a few fixing issues introduced during the recent
merge window too. There's also a fix for the xgene PMU driver, but it
seemed daft to send as a separate pull request, so I've included it
here with the rest of the fixes. More details in the tag.
Thanks,
Will
--->8
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git tags/arm64-fixes
for you to fetch changes up to f7881bd644474a4a62d7bd1ec801176f635f59ae:
arm64: remove pr_cont abuse from mem_init (2016-10-20 15:27:56 +0100)
----------------------------------------------------------------
arm64 fixes:
- Fix ACPI boot due to recent broken NUMA changes
- Fix remote enabling of CPU features requiring PSTATE bit manipulation
- Add address range check when emulating user cache maintenance
- Fix LL/SC loops that allow compiler to introduce memory accesses
- Fix recently added write_sysreg_s macro
- Ensure MDCR_EL2 is initialised on qemu targets without a PMU
- Avoid kaslr breakage due to MODVERSIONs and DYNAMIC_FTRACE
- Correctly drive recent ld when building relocatable Image
- Remove junk IS_ERR check from xgene PMU driver added during merge window
- pr_cont fixes after core changes in the merge window
----------------------------------------------------------------
Andre Przywara (1):
arm64: Cortex-A53 errata workaround: check for kernel addresses
Ard Biesheuvel (3):
arm64: kaslr: fix breakage with CONFIG_MODVERSIONS=y
arm64: kaslr: keep modules close to the kernel when DYNAMIC_FTRACE=y
arm64: kernel: force ET_DYN ELF type for CONFIG_RELOCATABLE=y
James Morse (3):
arm64: cpufeature: Schedule enable() calls instead of calling them via IPI
arm64: mm: Set PSTATE.PAN from the cpu_enable_pan() call
arm64: suspend: Reconfigure PSTATE after resume from idle
Lorenzo Pieralisi (1):
arm64: kernel: numa: fix ACPI boot cpu numa node mapping
Marc Zyngier (1):
arm64: kernel: Init MDCR_EL2 even in the absence of a PMU
Mark Rutland (2):
arm64: fix show_regs fallout from KERN_CONT changes
arm64: remove pr_cont abuse from mem_init
Tai Nguyen (1):
perf: xgene: Remove bogus IS_ERR() check
Will Deacon (3):
arm64: sysreg: Fix use of XZR in write_sysreg_s
arm64: swp emulation: bound LL/SC retries before rescheduling
arm64: percpu: rewrite ll/sc loops in assembly
arch/arm64/Kconfig | 2 +-
arch/arm64/Makefile | 2 +-
arch/arm64/include/asm/cpufeature.h | 2 +-
arch/arm64/include/asm/exec.h | 3 +
arch/arm64/include/asm/module.h | 5 ++
arch/arm64/include/asm/percpu.h | 120 ++++++++++++++++-------------------
arch/arm64/include/asm/processor.h | 6 +-
arch/arm64/include/asm/sysreg.h | 2 +-
arch/arm64/include/asm/uaccess.h | 8 +++
arch/arm64/kernel/armv8_deprecated.c | 36 +++++++----
arch/arm64/kernel/cpu_errata.c | 3 +-
arch/arm64/kernel/cpufeature.c | 10 ++-
arch/arm64/kernel/head.S | 3 +-
arch/arm64/kernel/process.c | 18 ++++--
arch/arm64/kernel/smp.c | 1 +
arch/arm64/kernel/suspend.c | 11 ++++
arch/arm64/kernel/traps.c | 30 +++++----
arch/arm64/mm/fault.c | 15 ++++-
arch/arm64/mm/init.c | 26 ++++----
drivers/perf/xgene_pmu.c | 2 +-
20 files changed, 184 insertions(+), 121 deletions(-)
^ permalink raw reply
* [PATCH 8/8] ARM: gr8: Add CHIP Pro support
From: Maxime Ripard @ 2016-10-20 17:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v67S8rK6Hdkvkgtfz6hDtiR4a4yUUqB01AnQ4sJ3-SQc0A@mail.gmail.com>
On Thu, Oct 20, 2016 at 10:26:09PM +0800, Chen-Yu Tsai wrote:
> On Thu, Oct 20, 2016 at 4:12 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > The CHIP Pro is a small embeddable board. It features a GR8, an AXP209
> > PMIC, a 512MB SLC NAND and a WiFi/BT chip.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>
> Acked-by: Chen-Yu Tsai <wens@csie.org>
Applied. Thanks for reviewing!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161020/554a8cfd/attachment.sig>
^ permalink raw reply
* [PATCH 7/8] ARM: gr8: Add UART3 pins
From: Maxime Ripard @ 2016-10-20 17:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v65OXss+_jKMSJD-KUDeK2iH96mmvDvPEzgW60PUXoS90g@mail.gmail.com>
On Thu, Oct 20, 2016 at 10:16:11PM +0800, Chen-Yu Tsai wrote:
> On Thu, Oct 20, 2016 at 4:12 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > The UART3 pins were missing from the DTSI. Add them.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>
> Acked-by: Chen-Yu Tsai <wens@csie.org>
Applied
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161020/35b9f488/attachment.sig>
^ permalink raw reply
* [PATCH 6/8] ARM: gr8: Add UART2 pins
From: Maxime Ripard @ 2016-10-20 17:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v641SWJTG=3AmHE3zAypuoq7fL7gFLBXwfXpmCYw7K0Guw@mail.gmail.com>
On Thu, Oct 20, 2016 at 10:14:09PM +0800, Chen-Yu Tsai wrote:
> On Thu, Oct 20, 2016 at 4:12 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > The UART2 pins were missing from the DTSI. Add them.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>
> Acked-by: Chen-Yu Tsai <wens@csie.org>
Applied.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161020/2ea1e28b/attachment.sig>
^ permalink raw reply
* [PATCH 5/8] ARM: gr8: Add missing pwm channel 1 pin
From: Maxime Ripard @ 2016-10-20 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v66w0sTzn_SWH4rrpWKOosSxALV8ot3CBQbGhwLxvX1vxw@mail.gmail.com>
On Thu, Oct 20, 2016 at 10:10:03PM +0800, Chen-Yu Tsai wrote:
> On Thu, Oct 20, 2016 at 4:12 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > The PWM controller has two different channels, but only the first pin was
> > exposed in the DTSI. Add the other one.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>
> Acked-by: Chen-Yu Tsai <wens@csie.org>
>
> > ---
> > arch/arm/boot/dts/ntc-gr8.dtsi | 7 +++++++
> > 1 file changed, 7 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/ntc-gr8.dtsi b/arch/arm/boot/dts/ntc-gr8.dtsi
> > index 74aff795e723..fad7381630f3 100644
> > --- a/arch/arm/boot/dts/ntc-gr8.dtsi
> > +++ b/arch/arm/boot/dts/ntc-gr8.dtsi
> > @@ -854,6 +854,13 @@
> > allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> > };
> >
> > + pwm1_pins_a: pwm1 at 0 {
>
> Nit: really don't need "_a" and "@0" here.
Fixed and applied.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161020/8e9d5601/attachment-0001.sig>
^ permalink raw reply
* [PATCH 4/8] ARM: gr8: Fix typo in the i2s mclk pin group
From: Maxime Ripard @ 2016-10-20 17:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v65P6WEZCy8AXCk5mV4gWgiWuZJiDZzJnEgr+sj9qf8ORA@mail.gmail.com>
On Thu, Oct 20, 2016 at 10:07:46PM +0800, Chen-Yu Tsai wrote:
> On Thu, Oct 20, 2016 at 4:12 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > There was a dumb copy and paste mistake here, fix it.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>
> Acked-by: Chen-Yu Tsai <wens@csie.org>
Applied.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161020/a2f2fddd/attachment.sig>
^ permalink raw reply
* [PATCH 3/8] ARM: gr8: Add the UART3
From: Maxime Ripard @ 2016-10-20 17:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v65iR=mZyCQrF64HOku5Sq7fNKGhV=Yy3zUFYzB=4ozkWg@mail.gmail.com>
On Thu, Oct 20, 2016 at 10:06:47PM +0800, Chen-Yu Tsai wrote:
> On Thu, Oct 20, 2016 at 4:12 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > The GR8 has access to the UART3 controller, which was missing in the
> > DTSI. Add it.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
>
> Acked-by: Chen-Yu Tsai <wens@csie.org>
Applied.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161020/9ecfcb79/attachment.sig>
^ permalink raw reply
* [PATCH v2] ARM: bcm2835: Add names for the Raspberry Pi GPIO lines
From: Eric Anholt @ 2016-10-20 17:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdb++5Xb6a=0Zz5eZURNmrkfVyvsBR-pLK9iRiyTu1g8Rw@mail.gmail.com>
Linus Walleij <linus.walleij@linaro.org> writes:
> On Tue, Oct 18, 2016 at 10:44 PM, Gottfried Haider
> <gottfried.haider@gmail.com wrote:
>
>> Regarding the proposed format using the header pin numbers: From what I've
>> seen in terms of existing educational materials, it seems the overwhelming
>> majority ends up using GPIO numbers instead of physical pin header
>> numbering. (e.g. [1] [2])
>
> What does that number mean? If you are referring to the global
> GPIO numberspace it is obsolete and just reflecting the fact that
> people up until now was referring to Linux-internal GPIO numbers.
The number within the SOC's GPIOs. Until the 8-line expander that's
been hung off the SOC GPIOs in the Pi3, they were the only GPIOs in the
system.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161020/3bd2a4ea/attachment.sig>
^ permalink raw reply
* [PATCH -next] net: ethernet: mediatek: use dev_kfree_skb_any instead of dev_kfree_skb
From: Wei Yongjun @ 2016-10-20 17:00 UTC (permalink / raw)
To: linux-arm-kernel
From: Wei Yongjun <weiyongjun1@huawei.com>
Replace dev_kfree_skb with dev_kfree_skb_any in mtk_start_xmit()
which can be called from hard irq context (netpoll) and from
other contexts. mtk_start_xmit() only frees skbs that it has
dropped.
This is detected by Coccinelle semantic patch.
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
---
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 8f80e61..d716274 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -843,7 +843,7 @@ static int mtk_start_xmit(struct sk_buff *skb, struct net_device *dev)
drop:
spin_unlock(ð->page_lock);
stats->tx_dropped++;
- dev_kfree_skb(skb);
+ dev_kfree_skb_any(skb);
return NETDEV_TX_OK;
}
^ permalink raw reply related
* [PATCH v2] ARM: bcm2835: Add names for the Raspberry Pi GPIO lines
From: Gottfried Haider @ 2016-10-20 16:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdb++5Xb6a=0Zz5eZURNmrkfVyvsBR-pLK9iRiyTu1g8Rw@mail.gmail.com>
> The old sysfs interface is not changing. However it is deprecated so once
> you have a v4.8+ kernel, consider migrating whatever userspace you have
> to use the chardev ABI instead.
>
> See:
> commit fe95046e960b4b76e73dc1486955d93f47276134
> "gpio: ABI: mark the sysfs ABI as obsolete"
> commit 521a2ad6f862a28e2e43cb3e254a26bf0f9452e9
> "gpio: add userspace ABI for GPIO line information"
> commit d7c51b47ac11e66f547b55640405c1c474642d72
> "gpio: userspace ABI for reading/writing GPIO lines"
> commit 61f922db72216b00386581c851db9c9095961522
> "gpio: userspace ABI for reading GPIO line events"
Thanks for those pointers. Somewhat off topic: is it planned to add
support for setting GENERIC_PINCONF style pull-up/pull-down resistors
throigh the new ABI? (The bcm28xx drivers would still need to
converted to this as well.)
>> Regarding the proposed format using the header pin numbers: From what I've
>> seen in terms of existing educational materials, it seems the overwhelming
>> majority ends up using GPIO numbers instead of physical pin header
>> numbering. (e.g. [1] [2])
>
> What does that number mean? If you are referring to the global
> GPIO numberspace it is obsolete and just reflecting the fact that
> people up until now was referring to Linux-internal GPIO numbers.
I am referring to the name of the various GPIO lines as per datasheet
("GPIO0", "GPIO1", ...). So far, I believe those matched the global
GPIO numberspace.
>> Would it be too confusing to try to pick GPIO 5 from an alphabetically
>> sorted list like this "P11_GPIO17", "P12_GPIO18"? (I know, alphabetical
>> sorting is an issue here already for a different reason. But applications
>> might do it, I guess?)
>
> Any attempt to preserve the global GPIO numberspace is futile.
> If it is the local offset number on the chip it is another thing, that
> is kind of OK if the arch maintainer likes it.
I understand that Linux can't guarantee a certain global GPIO number -
but I fear that the board manufacturers also might not think of the
pin headers as something set in stone (that the can't rearrange in a
future revision/product).
Would there be a reason against _naming_ the pin "GPIO0"? (even if it
ends up with a different global, internal number)
Thanks & best
Gottfried
^ permalink raw reply
* [PATCH v14 5/9] clocksource/drivers/arm_arch_timer: Simplify ACPI support code.
From: Mark Rutland @ 2016-10-20 16:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475086637-1914-6-git-send-email-fu.wei@linaro.org>
On Thu, Sep 29, 2016 at 02:17:13AM +0800, fu.wei at linaro.org wrote:
> From: Fu Wei <fu.wei@linaro.org>
>
> The patch update arm_arch_timer driver to use the function
> provided by the new GTDT driver of ACPI.
> By this way, arm_arch_timer.c can be simplified, and separate
> all the ACPI GTDT knowledge from this timer driver.
>
> Signed-off-by: Fu Wei <fu.wei@linaro.org>
> Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
This generally looks fine, but:
> + arch_timer_ppi[PHYS_SECURE_PPI] = acpi_gtdt_map_ppi(PHYS_SECURE_PPI);
As mentioned on the prior patch, I think we shouldn't bother parsing the
secure interrupt, given the problem with the GSIV, and the fact that we
shouldn't need it in Linux.
> + arch_timer_ppi[PHYS_NONSECURE_PPI] = acpi_gtdt_map_ppi(PHYS_NONSECURE_PPI);
> + arch_timer_ppi[VIRT_PPI] = acpi_gtdt_map_ppi(VIRT_PPI);
> + arch_timer_ppi[HYP_PPI] = acpi_gtdt_map_ppi(HYP_PPI);
> + /* Always-on capability */
> + arch_timer_c3stop = acpi_gtdt_c3stop();
... I think we should check the flag on the relevant interrupt, though
that's worth clarifying.
>
> - /* Always-on capability */
> - arch_timer_c3stop = !(gtdt->non_secure_el1_flags & ACPI_GTDT_ALWAYS_ON);
> + if (timer_count < 0)
> + pr_err("Failed to get platform timer info.\n");
Why don't we log this in the code that would try to initialise the MMIO
timer? We can still fail after this.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 2/3] ARM: bus: da8xx-syscfg: new driver
From: Kevin Hilman @ 2016-10-20 16:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2278105.geKhb8xoNC@avalon>
+Arnd, Olof
Laurent Pinchart <laurent.pinchart@ideasonboard.com> writes:
> Hi Bartosz,
>
> On Wednesday 19 Oct 2016 10:26:57 Bartosz Golaszewski wrote:
>> 2016-10-18 22:49 GMT+02:00 Laurent Pinchart:
>> > On Monday 17 Oct 2016 18:30:49 Bartosz Golaszewski wrote:
>> >> Create the driver for the da8xx System Configuration and implement
>> >> support for writing to the three Master Priority registers.
>> >>
>> >> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>
>> [snip]
>>
>> >> +
>> >> +Documentation:
>> >> +OMAP-L138 (DA850) - http://www.ti.com/lit/ug/spruh82c/spruh82c.pdf
>> >> +
>> >> +Required properties:
>> >> +
>> >> +- compatible: "ti,da850-syscfg"
>> >
>> > Don't you need a reg property ?
>>
>> Yes, Kevin already pointed that out. I'll add it in v2. Same for [1/3].
>>
>> >> +Optional properties:
>> >> +
>> >> +The below properties are used to specify the priority of master
>> >> peripherals.
>> >> +They must be between 0-7 where 0 is the highest priority and 7 is the
>> >> lowest.
>> >> +
>> >> +- ti,pri-arm-i: ARM_I port priority.
>> >> +
>> >> +- ti,pri-arm-d: ARM_D port priority.
>> >> +
>> >> +- ti,pri-upp: uPP port priority.
>> >> +
>> >> +- ti,pri-sata: SATA port priority.
>> >> +
>> >> +- ti,pri-pru0: PRU0 port priority.
>> >> +
>> >> +- ti,pri-pru1: PRU1 port priority.
>> >> +
>> >> +- ti,pri-edma30tc0: EDMA3_0_TC0 port priority.
>> >> +
>> >> +- ti,pri-edma30tc1: EDMA3_0_TC1 port priority.
>> >> +
>> >> +- ti,pri-edma31tc0: EDMA3_1_TC0 port priority.
>> >> +
>> >> +- ti,pri-vpif-dma-0: VPIF DMA0 port priority.
>> >> +
>> >> +- ti,pri-vpif-dma-1: VPIF DMA1 port priority.
>> >> +
>> >> +- ti,pri-emac: EMAC port priority.
>> >> +
>> >> +- ti,pri-usb0cfg: USB0 CFG port priority.
>> >> +
>> >> +- ti,pri-usb0cdma: USB0 CDMA port priority.
>> >> +
>> >> +- ti,pri-uhpi: HPI port priority.
>> >> +
>> >> +- ti,pri-usb1: USB1 port priority.
>> >> +
>> >> +- ti,pri-lcdc: LCDC port priority.
>> >
>> > I'm afraid this looks more like system configuration than hardware
>> > description to me.
>>
>> While you're certainly right, this approach is already implemented in
>> several other memory and bus drivers and it was also suggested by
>> Sekhar in one of the tilcdc rev1 threads. There's also no real
>> alternative that I know of.
>
> The fact that other drivers get it wrong is no excuse for copying them :-)
What exactly is "wrong" with the way other drivers are doing it?
I'm sure there may be other ideas, and possibly some better ones, but
that doesn't make it wrong, and doesn't change he fact that the kernel
has existing drivers SoC-bus-specific system performance knobs like
this.
>> > There was a BoF session about how to support this kind of performance
>> > knobs at ELCE last week:
>> > https://openiotelceurope2016.sched.org/event/7rss/bof-linux-device-perfor
>> > mance-framework-michael-turquette-baylibre :-)
>>
>> Unfortunately it was just a discussion about potential approaches -
>> there's no code yet.
>
> Patches are welcome ;-)
Any generic perf framework will have to build on the HW-specifics of
individual busses, so IMO, the lack of a generic performance
framework/knobs should not be a reason to block the inclusion of any
bus-specific knobs.
I guess this ultimately would go though arm-soc, so I've added Arnd &
Olof to the thread.
Kevin
^ permalink raw reply
* [PATCH V5 1/2] ACPI: Add support for ResourceSource/IRQ domain mapping
From: Lorenzo Pieralisi @ 2016-10-20 16:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476812509-2760-2-git-send-email-agustinv@codeaurora.org>
Hi Agustin,
On Tue, Oct 18, 2016 at 01:41:48PM -0400, Agustin Vega-Frias wrote:
> This allows irqchip drivers to associate an ACPI DSDT device to
> an IRQ domain and provides support for using the ResourceSource
> in Extended IRQ Resources to find the domain and map the IRQs
> specified on that domain.
>
> Signed-off-by: Agustin Vega-Frias <agustinv@codeaurora.org>
> ---
> drivers/acpi/Makefile | 1 +
> drivers/acpi/irqdomain.c | 141 ++++++++++++++++++++++++++++++++++++++
> drivers/acpi/resource.c | 21 +++---
> include/asm-generic/vmlinux.lds.h | 1 +
> include/linux/acpi.h | 71 +++++++++++++++++++
> include/linux/irqchip.h | 17 ++++-
> 6 files changed, 240 insertions(+), 12 deletions(-)
> create mode 100644 drivers/acpi/irqdomain.c
>
> diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
> index 9ed0878..880401b 100644
> --- a/drivers/acpi/Makefile
> +++ b/drivers/acpi/Makefile
> @@ -57,6 +57,7 @@ acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
> acpi-y += acpi_lpat.o
> acpi-$(CONFIG_ACPI_GENERIC_GSI) += gsi.o
> acpi-$(CONFIG_ACPI_WATCHDOG) += acpi_watchdog.o
> +acpi-$(CONFIG_IRQ_DOMAIN) += irqdomain.o
>
> # These are (potentially) separate modules
>
> diff --git a/drivers/acpi/irqdomain.c b/drivers/acpi/irqdomain.c
> new file mode 100644
> index 0000000..c53b9f4
> --- /dev/null
> +++ b/drivers/acpi/irqdomain.c
> @@ -0,0 +1,141 @@
> +/*
> + * ACPI ResourceSource/IRQ domain mapping support
> + *
> + * Copyright (c) 2016, The Linux Foundation. All rights reserved.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 and
> + * only version 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +#include <linux/acpi.h>
> +#include <linux/irq.h>
> +#include <linux/irqdomain.h>
> +
> +/**
> + * acpi_irq_domain_ensure_probed() - Check if the device has registered
> + * an IRQ domain and probe as necessary
> + *
> + * @device: Device to check and probe
> + *
> + * Returns: 0 on success, -ENODEV otherwise
This is not correct (ie it depends on what
struct acpi_dsdt_probe_entry.probe
returns) and I would like to take this nit as an opportunity
to take a step back and ask you a question below.
> + */
> +static int acpi_irq_domain_ensure_probed(struct acpi_device *device)
> +{
> + struct acpi_dsdt_probe_entry *entry;
> +
> + if (irq_find_matching_fwnode(&device->fwnode, DOMAIN_BUS_ANY) != 0)
> + return 0;
> +
> + for (entry = &__dsdt_acpi_probe_table;
> + entry < &__dsdt_acpi_probe_table_end; entry++)
> + if (strcmp(entry->_hid, acpi_device_hid(device)) == 0)
> + return entry->probe(device);
Through this approch we are forcing an irqchip (that by the way it
has a physical node ACPI companion by being a DSDT device object so it
could be managed by a platform driver) to be probed. The question is: is
there a reason (apart from the current ACPI resource parsing API) why
this can't be implemented through deferred probing and the device
dependencies framework Rafael is working on:
http://www.mail-archive.com/linux-kernel at vger.kernel.org/msg1246897.html
The DT layer, through the of_irq_get() API, supports probe deferral
and what I am asking you is if there is any blocking point (again,
apart from the current ACPI API) to implement the same mechanism.
I have not reviewed the previous versions so I am certainly missing
some of the bits and pieces already discussed, apologies for that.
Thanks,
Lorenzo
> +
> + return -ENODEV;
> +}
> +
> +/**
> + * acpi_irq_domain_register_irq() - Register the mapping for an IRQ produced
> + * by the given acpi_resource_source to a
> + * Linux IRQ number
> + * @source: IRQ source
> + * @hwirq: Hardware IRQ number
> + * @trigger: trigger type of the IRQ number to be mapped
> + * @polarity: polarity of the IRQ to be mapped
> + *
> + * Returns: a valid linux IRQ number on success
> + * -ENODEV if the given acpi_resource_source cannot be found
> + * -EPROBE_DEFER if the IRQ domain has not been registered
> + * -EINVAL for all other errors
> + */
> +int acpi_irq_domain_register_irq(const struct acpi_resource_source *source,
> + u32 hwirq, int trigger, int polarity)
> +{
> + struct irq_fwspec fwspec;
> + struct acpi_device *device;
> + acpi_handle handle;
> + acpi_status status;
> + int ret;
> +
> + /* An empty acpi_resource_source means it is a GSI */
> + if (!source->string_length)
> + return acpi_register_gsi(NULL, hwirq, trigger, polarity);
> +
> + status = acpi_get_handle(NULL, source->string_ptr, &handle);
> + if (ACPI_FAILURE(status))
> + return -ENODEV;
> +
> + device = acpi_bus_get_acpi_device(handle);
> + if (!device)
> + return -ENODEV;
> +
> + ret = acpi_irq_domain_ensure_probed(device);
> + if (ret)
> + goto out_put_device;
> +
> + fwspec.fwnode = &device->fwnode;
> + fwspec.param[0] = hwirq;
> + fwspec.param[1] = acpi_dev_get_irq_type(trigger, polarity);
> + fwspec.param_count = 2;
> +
> + ret = irq_create_fwspec_mapping(&fwspec);
> +
> +out_put_device:
> + acpi_bus_put_acpi_device(device);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(acpi_irq_domain_register_irq);
> +
> +/**
> + * acpi_irq_domain_unregister_irq() - Delete the mapping for an IRQ produced
> + * by the given acpi_resource_source to a
> + * Linux IRQ number
> + * @source: IRQ source
> + * @hwirq: Hardware IRQ number
> + *
> + * Returns: 0 on success
> + * -ENODEV if the given acpi_resource_source cannot be found
> + * -EINVAL for all other errors
> + */
> +int acpi_irq_domain_unregister_irq(const struct acpi_resource_source *source,
> + u32 hwirq)
> +{
> + struct irq_domain *domain;
> + struct acpi_device *device;
> + acpi_handle handle;
> + acpi_status status;
> + int ret = 0;
> +
> + if (!source->string_length) {
> + acpi_unregister_gsi(hwirq);
> + return 0;
> + }
> +
> + status = acpi_get_handle(NULL, source->string_ptr, &handle);
> + if (ACPI_FAILURE(status))
> + return -ENODEV;
> +
> + device = acpi_bus_get_acpi_device(handle);
> + if (!device)
> + return -ENODEV;
> +
> + domain = irq_find_matching_fwnode(&device->fwnode, DOMAIN_BUS_ANY);
> + if (!domain) {
> + ret = -EINVAL;
> + goto out_put_device;
> + }
> +
> + irq_dispose_mapping(irq_find_mapping(domain, hwirq));
> +
> +out_put_device:
> + acpi_bus_put_acpi_device(device);
> +
> + return ret;
> +}
> +EXPORT_SYMBOL_GPL(acpi_irq_domain_unregister_irq);
> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> index 56241eb..3fb7abf 100644
> --- a/drivers/acpi/resource.c
> +++ b/drivers/acpi/resource.c
> @@ -381,14 +381,15 @@ static void acpi_dev_irqresource_disabled(struct resource *res, u32 gsi)
> res->flags = IORESOURCE_IRQ | IORESOURCE_DISABLED | IORESOURCE_UNSET;
> }
>
> -static void acpi_dev_get_irqresource(struct resource *res, u32 gsi,
> +static void acpi_dev_get_irqresource(struct resource *res, u32 hwirq,
> + const struct acpi_resource_source *source,
> u8 triggering, u8 polarity, u8 shareable,
> bool legacy)
> {
> int irq, p, t;
>
> - if (!valid_IRQ(gsi)) {
> - acpi_dev_irqresource_disabled(res, gsi);
> + if ((source->string_length == 0) && !valid_IRQ(hwirq)) {
> + acpi_dev_irqresource_disabled(res, hwirq);
> return;
> }
>
> @@ -402,25 +403,25 @@ static void acpi_dev_get_irqresource(struct resource *res, u32 gsi,
> * using extended IRQ descriptors we take the IRQ configuration
> * from _CRS directly.
> */
> - if (legacy && !acpi_get_override_irq(gsi, &t, &p)) {
> + if (legacy && !acpi_get_override_irq(hwirq, &t, &p)) {
> u8 trig = t ? ACPI_LEVEL_SENSITIVE : ACPI_EDGE_SENSITIVE;
> u8 pol = p ? ACPI_ACTIVE_LOW : ACPI_ACTIVE_HIGH;
>
> if (triggering != trig || polarity != pol) {
> - pr_warning("ACPI: IRQ %d override to %s, %s\n", gsi,
> - t ? "level" : "edge", p ? "low" : "high");
> + pr_warn("ACPI: IRQ %d override to %s, %s\n", hwirq,
> + t ? "level" : "edge", p ? "low" : "high");
> triggering = trig;
> polarity = pol;
> }
> }
>
> res->flags = acpi_dev_irq_flags(triggering, polarity, shareable);
> - irq = acpi_register_gsi(NULL, gsi, triggering, polarity);
> + irq = acpi_irq_domain_register_irq(source, hwirq, triggering, polarity);
> if (irq >= 0) {
> res->start = irq;
> res->end = irq;
> } else {
> - acpi_dev_irqresource_disabled(res, gsi);
> + acpi_dev_irqresource_disabled(res, hwirq);
> }
> }
>
> @@ -446,6 +447,7 @@ static void acpi_dev_get_irqresource(struct resource *res, u32 gsi,
> bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
> struct resource *res)
> {
> + const struct acpi_resource_source dummy = { 0, 0, NULL };
> struct acpi_resource_irq *irq;
> struct acpi_resource_extended_irq *ext_irq;
>
> @@ -460,7 +462,7 @@ bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
> acpi_dev_irqresource_disabled(res, 0);
> return false;
> }
> - acpi_dev_get_irqresource(res, irq->interrupts[index],
> + acpi_dev_get_irqresource(res, irq->interrupts[index], &dummy,
> irq->triggering, irq->polarity,
> irq->sharable, true);
> break;
> @@ -471,6 +473,7 @@ bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
> return false;
> }
> acpi_dev_get_irqresource(res, ext_irq->interrupts[index],
> + &ext_irq->resource_source,
> ext_irq->triggering, ext_irq->polarity,
> ext_irq->sharable, false);
> break;
> diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
> index 3074796..f808afdc 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -563,6 +563,7 @@
> IRQCHIP_OF_MATCH_TABLE() \
> ACPI_PROBE_TABLE(irqchip) \
> ACPI_PROBE_TABLE(clksrc) \
> + ACPI_PROBE_TABLE(dsdt) \
> EARLYCON_TABLE()
>
> #define INIT_TEXT \
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index ddbeda6..bb1a838 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -26,6 +26,7 @@
> #include <linux/resource_ext.h>
> #include <linux/device.h>
> #include <linux/property.h>
> +#include <linux/irqdomain.h>
>
> #ifndef _LINUX
> #define _LINUX
> @@ -321,6 +322,31 @@ void acpi_set_irq_model(enum acpi_irq_model_id model,
> */
> void acpi_unregister_gsi (u32 gsi);
>
> +#ifdef CONFIG_IRQ_DOMAIN
> +
> +int acpi_irq_domain_register_irq(const struct acpi_resource_source *source,
> + u32 hwirq, int trigger, int polarity);
> +int acpi_irq_domain_unregister_irq(const struct acpi_resource_source *source,
> + u32 hwirq);
> +
> +#else
> +
> +static inline int acpi_irq_domain_register_irq(
> + const struct acpi_resource_source *source, u32 hwirq, int trigger,
> + int polarity)
> +{
> + return acpi_register_gsi(NULL, hwirq, trigger, polarity);
> +}
> +
> +static inline int acpi_irq_domain_unregister_irq(
> + const struct acpi_resource_source *source, u32 hwirq)
> +{
> + acpi_unregister_gsi(hwirq);
> + return 0;
> +}
> +
> +#endif /* CONFIG_IRQ_DOMAIN */
> +
> struct pci_dev;
>
> int acpi_pci_irq_enable (struct pci_dev *dev);
> @@ -1024,6 +1050,34 @@ struct acpi_probe_entry {
> (&ACPI_PROBE_TABLE_END(t) - \
> &ACPI_PROBE_TABLE(t))); \
> })
> +
> +/* Length of Hardware ID field in DSDT entries as per ACPI spec */
> +#define ACPI_HID_LEN 9
> +
> +typedef int (*acpi_dsdt_handler)(struct acpi_device *);
> +
> +/**
> + * struct acpi_probe_dsdt_entry - boot-time probing entry for DSDT devices
> + * @hid: _HID of the device
> + * @fn: Callback to the driver being probed
> + * @driver_data: Sideband data provided back to the driver
> + */
> +struct acpi_dsdt_probe_entry {
> + __u8 _hid[ACPI_HID_LEN];
> + acpi_dsdt_handler probe;
> +};
> +
> +#define ACPI_DECLARE_DSDT_PROBE_ENTRY(name, hid, fn) \
> + static const struct acpi_dsdt_probe_entry __acpi_probe_##name \
> + __used __section(__dsdt_acpi_probe_table) = \
> + { \
> + ._hid = hid, \
> + .probe = fn, \
> + }
> +
> +extern struct acpi_dsdt_probe_entry __dsdt_acpi_probe_table;
> +extern struct acpi_dsdt_probe_entry __dsdt_acpi_probe_table_end;
> +
> #else
> static inline int acpi_dev_get_property(struct acpi_device *adev,
> const char *name, acpi_object_type type,
> @@ -1101,8 +1155,25 @@ static inline struct fwnode_handle *acpi_get_next_subnode(struct device *dev,
> (void *) data }
>
> #define acpi_probe_device_table(t) ({ int __r = 0; __r;})
> +
> +#define ACPI_DECLARE_DSDT_PROBE_ENTRY(name, hid, fn) \
> + static const void *__acpi_probe_##name[] \
> + __attribute__((unused)) \
> + = { (void *) hid, \
> + (void *) fn }
> +
> #endif
>
> +#define MADT_IRQCHIP_ACPI_DECLARE(name, subtable, validate, data, fn) \
> + ACPI_DECLARE_PROBE_ENTRY(irqchip, name, ACPI_SIG_MADT, \
> + subtable, validate, data, fn)
> +
> +#define DSDT_IRQCHIP_ACPI_DECLARE(name, hid, fn) \
> + ACPI_DECLARE_DSDT_PROBE_ENTRY(name, hid, fn)
> +
> +#define __IRQCHIP_ACPI_DECLARE(_a1, _a2, _a3, _a4, _a5, type, ...) \
> + type##_IRQCHIP_ACPI_DECLARE
> +
> #ifdef CONFIG_ACPI_TABLE_UPGRADE
> void acpi_table_upgrade(void);
> #else
> diff --git a/include/linux/irqchip.h b/include/linux/irqchip.h
> index 89c34b2..c2d0c12 100644
> --- a/include/linux/irqchip.h
> +++ b/include/linux/irqchip.h
> @@ -29,6 +29,10 @@
> /*
> * This macro must be used by the different irqchip drivers to declare
> * the association between their version and their initialization function.
> + * Two syntaxes are supported depending on the table where the irqchip device
> + * is declared:
> + *
> + * - MADT irqchip syntax, which requires the following five arguments:
> *
> * @name: name that must be unique accross all IRQCHIP_ACPI_DECLARE of the
> * same file.
> @@ -37,10 +41,17 @@
> * Can be NULL.
> * @data: data to be checked by the validate function.
> * @fn: initialization function
> + *
> + * - DSDT irqchip syntax, which requires the following three arguments:
> + *
> + * @name: name that must be unique across all IRQCHIP_ACPI_DECLARE of the
> + * same file.
> + * @hid: _HID of the DSDT device
> + * @fn: initialization function
> */
> -#define IRQCHIP_ACPI_DECLARE(name, subtable, validate, data, fn) \
> - ACPI_DECLARE_PROBE_ENTRY(irqchip, name, ACPI_SIG_MADT, \
> - subtable, validate, data, fn)
> +
> +#define IRQCHIP_ACPI_DECLARE(...) \
> + __IRQCHIP_ACPI_DECLARE(__VA_ARGS__, MADT, _unused, DSDT)(__VA_ARGS__)
>
> #ifdef CONFIG_IRQCHIP
> void irqchip_init(void);
> --
> Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, Inc.
> Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* [PATCH V6 00/10] dmaengine: qcom_hidma: add MSI interrupt support
From: Vinod Koul @ 2016-10-20 16:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e3cbd6a2-7fac-98ec-74ea-0be88075663c@codeaurora.org>
On Thu, Oct 20, 2016 at 07:06:08AM -0700, Sinan Kaya wrote:
> Hi Vinod,
>
> On 10/20/2016 2:48 AM, Vinod Koul wrote:
> >> 6:
> >> > * rebase 4.9 kernel
> > Why???
> >
>
> This is more for me. There is nothing special about 4.9 that impacts hidma.
> It just means that I retested the code against 4.9-rc1 kernel.
>
> >
> > I already told you that I have applied 6 in the last version, please dont
> > send me stuff which is already applied :(
>
> I couldn't find your applied branch on git yesterday. That's why, I sent you
> the whole thing so that you can pick the last 4 ones. You don't need to reapply
> the first 6. Better to have everything than missing code.
>
> 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!!
> If you prefer a reduced list, please make your current changelist available on
> one of the branches on git, I can reapply, test and send only the remaining ones.
>
> 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.
--
~Vinod
^ permalink raw reply
* [PATCH v14 4/9] acpi/arm64: Add GTDT table parse driver
From: Mark Rutland @ 2016-10-20 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475086637-1914-5-git-send-email-fu.wei@linaro.org>
Hi,
As a heads-up, on v4.9-rc1 I see conflicts at least against
arch/arm64/Kconfig. Luckily git am -3 seems to be able to fix that up
automatically, but this will need to be rebased before the next posting
and/or merging.
On Thu, Sep 29, 2016 at 02:17:12AM +0800, fu.wei at linaro.org wrote:
> +static int __init map_gt_gsi(u32 interrupt, u32 flags)
> +{
> + int trigger, polarity;
> +
> + if (!interrupt)
> + return 0;
Urgh.
Only the secure interrupt (which we do not need) is optional in this
manner, and (hilariously), zero appears to also be a valid GSIV, per
figure 5-24 in the ACPI 6.1 spec.
So, I think that:
(a) we should not bother parsing the secure interrupt
(b) we should drop the check above
(c) we should report the spec issue to the ASWG
> +/*
> + * acpi_gtdt_c3stop - got c3stop info from GTDT
> + *
> + * Returns 1 if the timer is powered in deep idle state, 0 otherwise.
> + */
> +bool __init acpi_gtdt_c3stop(void)
> +{
> + struct acpi_table_gtdt *gtdt = acpi_gtdt_desc.gtdt;
> +
> + return !(gtdt->non_secure_el1_flags & ACPI_GTDT_ALWAYS_ON);
> +}
It looks like this can differ per interrupt. Shouldn't we check the
appropriate one?
> +int __init acpi_gtdt_init(struct acpi_table_header *table)
> +{
> + void *start;
> + struct acpi_table_gtdt *gtdt;
> +
> + gtdt = container_of(table, struct acpi_table_gtdt, header);
> +
> + acpi_gtdt_desc.gtdt = gtdt;
> + acpi_gtdt_desc.gtdt_end = (void *)table + table->length;
> +
> + if (table->revision < 2) {
> + pr_debug("Revision:%d doesn't support Platform Timers.\n",
> + table->revision);
> + return 0;
> + }
> +
> + if (!gtdt->platform_timer_count) {
> + pr_debug("No Platform Timer.\n");
> + return 0;
> + }
> +
> + start = (void *)gtdt + gtdt->platform_timer_offset;
> + if (start < (void *)table + sizeof(struct acpi_table_gtdt)) {
> + pr_err(FW_BUG "Failed to retrieve timer info from firmware: invalid data.\n");
> + return -EINVAL;
> + }
> + acpi_gtdt_desc.platform_timer_start = start;
> +
> + return gtdt->platform_timer_count;
> +}
This is never used as anything other than a status code.
Just return zero; we haven't parsed the platform timers themselves at
this point anyway.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v2] arm64: Add support for additional relocations in the kexec purgatory code
From: Geoff Levand @ 2016-10-20 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476960211-25594-1-git-send-email-catalin.marinas@arm.com>
On 10/20/2016 03:43 AM, Catalin Marinas wrote:
> When compiling the kexec-tools with gcc6, the following additional
> reolcations are generated in the purgatory.ro file:
>
> R_AARCH64_ADR_PREL_PG_HI21
> R_AARCH64_ADD_ABS_LO12_NC
> R_AARCH64_LDST64_ABS_LO12_NC
Looks good. Simon, please apply.
Reviewed-by: Geoff Levand <geoff@infradead.org>
^ permalink raw reply
* [PATCH v2 6/9] ARM64: meson: enable MESON_IRQ_GPIO in Kconfig
From: Marc Zyngier @ 2016-10-20 16:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476890480-8884-7-git-send-email-jbrunet@baylibre.com>
On 19/10/16 16:21, Jerome Brunet wrote:
> Add select MESON_IRQ_GPIO in Kconfig for Amlogic's meson SoC family
>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
> arch/arm64/Kconfig.platforms | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
> index cfbdf02ef566..846479d4492d 100644
> --- a/arch/arm64/Kconfig.platforms
> +++ b/arch/arm64/Kconfig.platforms
> @@ -95,6 +95,7 @@ config ARCH_MESON
> select PINCTRL_MESON
> select COMMON_CLK_AMLOGIC
> select COMMON_CLK_GXBB
> + select MESON_GPIO_IRQ
MESON_IRQ_GPIO?
> help
> This enables support for the Amlogic S905 SoCs.
>
>
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v2 1/9] irqchip: meson: add support for gpio interrupt controller
From: Marc Zyngier @ 2016-10-20 16:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1476890480-8884-2-git-send-email-jbrunet@baylibre.com>
Jerome,
On 19/10/16 16:21, Jerome Brunet wrote:
> Add support for the interrupt gpio controller found on Amlogic's meson
> SoC family.
>
> Unlike what the IP name suggest, it is not directly linked to the gpio
> subsystem. It is actually an independent IP that is able to spy on the
> SoC pad. For that purpose, it can mux and filter (edge or level and
> polarity) any single SoC pad to one of the 8 GIC's interrupts it owns.
>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
> ---
> drivers/irqchip/Kconfig | 9 +
> drivers/irqchip/Makefile | 1 +
> drivers/irqchip/irq-meson-gpio.c | 423 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 433 insertions(+)
> create mode 100644 drivers/irqchip/irq-meson-gpio.c
>
> diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
> index 82b0b5daf3f5..168837263e80 100644
> --- a/drivers/irqchip/Kconfig
> +++ b/drivers/irqchip/Kconfig
> @@ -279,3 +279,12 @@ config EZNPS_GIC
> config STM32_EXTI
> bool
> select IRQ_DOMAIN
> +
> +config MESON_GPIO_IRQ
> + bool "Meson GPIO Interrupt Multiplexer"
> + depends on ARCH_MESON || COMPILE_TEST
> + select IRQ_DOMAIN
> + select IRQ_DOMAIN_HIERARCHY
> + help
> + Support Meson SoC Family GPIO Interrupt Multiplexer
> +
> diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
> index e4dbfc85abdb..33f913d037d0 100644
> --- a/drivers/irqchip/Makefile
> +++ b/drivers/irqchip/Makefile
> @@ -74,3 +74,4 @@ obj-$(CONFIG_LS_SCFG_MSI) += irq-ls-scfg-msi.o
> obj-$(CONFIG_EZNPS_GIC) += irq-eznps.o
> obj-$(CONFIG_ARCH_ASPEED) += irq-aspeed-vic.o
> obj-$(CONFIG_STM32_EXTI) += irq-stm32-exti.o
> +obj-$(CONFIG_MESON_GPIO_IRQ) += irq-meson-gpio.o
> diff --git a/drivers/irqchip/irq-meson-gpio.c b/drivers/irqchip/irq-meson-gpio.c
> new file mode 100644
> index 000000000000..869b4df8c483
> --- /dev/null
> +++ b/drivers/irqchip/irq-meson-gpio.c
> @@ -0,0 +1,423 @@
> +/*
> + * Copyright (c) 2015 Endless Mobile, Inc.
> + * Author: Carlo Caione <carlo@endlessm.com>
> + * Copyright (c) 2016 BayLibre, SAS.
> + * Author: Jerome Brunet <jbrunet@baylibre.com>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of version 2 of the GNU General Public License as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful, but
> + * WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, see <http://www.gnu.org/licenses/>.
> + * The full GNU General Public License is included in this distribution
> + * in the file called COPYING.
> + */
> +
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/irq.h>
> +#include <linux/irqdomain.h>
> +#include <linux/irqchip.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +
> +#define IRQ_FREE (-1)
> +
> +#define REG_EDGE_POL 0x00
> +#define REG_PIN_03_SEL 0x04
> +#define REG_PIN_47_SEL 0x08
> +#define REG_FILTER_SEL 0x0c
> +
> +#define REG_EDGE_POL_MASK(x) (BIT(x) | BIT(16 + (x)))
> +#define REG_EDGE_POL_EDGE(x) BIT(x)
> +#define REG_EDGE_POL_LOW(x) BIT(16 + (x))
> +#define REG_PIN_SEL_SHIFT(x) (((x) % 4) * 8)
> +#define REG_FILTER_SEL_SHIFT(x) ((x) * 4)
> +
> +struct meson_gpio_irq_params {
> + unsigned int nhwirq;
> + irq_hw_number_t *source;
> + int nsource;
> +};
> +
> +struct meson_gpio_irq_domain {
The name of that structure is utterly confusing, as it doesn't contain
anything related to an IRQ domain. Can you please clarify its usage?
> + void __iomem *base;
> + int *map;
> + const struct meson_gpio_irq_params *params;
> +};
> +
> +struct meson_gpio_irq_chip_data {
> + void __iomem *base;
> + int index;
> +};
> +
> +static irq_hw_number_t meson_parent_hwirqs[] = {
> + 64, 65, 66, 67, 68, 69, 70, 71,
> +};
If that a guarantee that these numbers will always represent the parent
interrupt? It feels a bit odd not to get that information directly from
the device tree, in the form of a device specific property. Something like:
upstream-interrupts = <64 65 66 ... >;
or even as a base/range:
upstream-interrupts = <64 8>;
Also, how does it work if you have more than a single device like this?
This driver seems a do a great deal of dynamic allocation, and yet its
core resource is completely static... Please pick a side! ;-)
> +
> +static const struct meson_gpio_irq_params meson8_params = {
> + .nhwirq = 134,
> + .source = meson_parent_hwirqs,
> + .nsource = ARRAY_SIZE(meson_parent_hwirqs),
I find it utterly confusing that you are calling source something that
is an output for this controller. It makes my brain melt, and I don't
like the feeling.
> +};
> +
> +static const struct meson_gpio_irq_params meson8b_params = {
> + .nhwirq = 119,
> + .source = meson_parent_hwirqs,
> + .nsource = ARRAY_SIZE(meson_parent_hwirqs),
> +};
> +
> +static const struct meson_gpio_irq_params meson_gxbb_params = {
> + .nhwirq = 133,
> + .source = meson_parent_hwirqs,
> + .nsource = ARRAY_SIZE(meson_parent_hwirqs),
> +};
Same thing. How big is the variability of these structures? Are we going
to see more of those? or is that now set into stone?
+Mark: what's the policy to describe this kind of things?
> +
> +static const struct of_device_id meson_irq_gpio_matches[] = {
> + {
> + .compatible = "amlogic,meson8-gpio-intc",
If it's an independent IP (as described in the commit message),
shouldn't in be rescribed in a more SoC-independent way?
> + .data = &meson8_params
> + },
> + {
> + .compatible = "amlogic,meson8b-gpio-intc",
> + .data = &meson8b_params
> + },
> + {
> + .compatible = "amlogic,meson-gxbb-gpio-intc",
> + .data = &meson_gxbb_params
> + },
> + {}
> +};
> +
> +static void meson_gpio_irq_update_bits(void __iomem *base, unsigned int reg,
> + u32 mask, u32 val)
> +{
> + u32 tmp;
> +
> + tmp = readl(base + reg);
> + tmp &= ~mask;
> + tmp |= val;
> +
> + writel(tmp, base + reg);
Can't you use the relaxed accessors?
> +}
> +
> +static int meson_gpio_irq_get_index(struct meson_gpio_irq_domain *domain_data,
> + int hwirq)
> +{
> + int i;
> +
> + for (i = 0; i < domain_data->params->nsource; i++) {
> + if (domain_data->map[i] == hwirq)
> + return i;
> + }
> +
> + return -1;
I'm a bit worried by this function. If you need an allocator, then
having a simple bitmap is much better than iterating over an array.
If you're using this to go from a hwirq to the structure describing your
interrupt, this is wrong. You should never have to look-up something
based on a hwirq, because that's what irq domains are for.
> +}
> +
> +static int mesion_gpio_irq_map_source(struct meson_gpio_irq_domain *domain_data,
> + irq_hw_number_t hwirq,
> + irq_hw_number_t *source)
> +{
> + int index;
> + unsigned int reg;
> +
> + index = meson_gpio_irq_get_index(domain_data, IRQ_FREE);
So assuming you turn this into a proper bitmap driven allocator...
> + if (index < 0) {
> + pr_err("No irq available\n");
> + return -ENOSPC;
> + }
> +
> + domain_data->map[index] = hwirq;
this can go away, as there is hardly any point in tracking the hwirq on
its own. Actually, the whole map[] array looks totally useless.
> +
> + reg = (index < 4) ? REG_PIN_03_SEL : REG_PIN_47_SEL;
> + meson_gpio_irq_update_bits(domain_data->base, reg,
> + 0xff << REG_PIN_SEL_SHIFT(index),
> + hwirq << REG_PIN_SEL_SHIFT(index));
> +
> + *source = domain_data->params->source[index];
> +
> + pr_debug("hwirq %lu assigned to channel %d - source %lu\n",
> + hwirq, index, *source);
> +
> + return index;
> +}
> +
> +static int meson_gpio_irq_type_setup(unsigned int type, void __iomem *base,
> + int index)
> +{
> + u32 val = 0;
> +
> + type &= IRQ_TYPE_SENSE_MASK;
> +
> + if (type == IRQ_TYPE_EDGE_BOTH)
> + return -EINVAL;
> +
> + if (type & (IRQ_TYPE_EDGE_RISING | IRQ_TYPE_EDGE_FALLING))
> + val |= REG_EDGE_POL_EDGE(index);
> +
> + if (type & (IRQ_TYPE_LEVEL_LOW | IRQ_TYPE_EDGE_FALLING))
> + val |= REG_EDGE_POL_LOW(index);
> +
> + meson_gpio_irq_update_bits(base, REG_EDGE_POL,
> + REG_EDGE_POL_MASK(index), val);
> +
> + return 0;
> +}
> +
> +static unsigned int meson_gpio_irq_type_output(unsigned int type)
> +{
> + unsigned int sense = type & IRQ_TYPE_SENSE_MASK;
> +
> + type &= ~IRQ_TYPE_SENSE_MASK;
> +
> + /*
> + * If the polarity of interrupt is low, the controller will
> + * invert the signal for gic
> + */
> + if (sense & (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_LEVEL_LOW))
> + type |= IRQ_TYPE_LEVEL_HIGH;
> + else if (sense & (IRQ_TYPE_EDGE_RISING | IRQ_TYPE_EDGE_FALLING))
> + type |= IRQ_TYPE_EDGE_RISING;
> +
> + return type;
> +}
> +
> +static int meson_gpio_irq_set_type(struct irq_data *data, unsigned int type)
> +{
> + struct meson_gpio_irq_chip_data *cd = irq_data_get_irq_chip_data(data);
> + int ret;
> +
> + pr_debug("set type of hwirq %lu to %u\n", data->hwirq, type);
> +
> + ret = meson_gpio_irq_type_setup(type, cd->base, cd->index);
> + if (ret)
> + return ret;
> +
> + return irq_chip_set_type_parent(data,
> + meson_gpio_irq_type_output(type));
> +}
> +
> +static struct irq_chip meson_gpio_irq_chip = {
> + .name = "meson-gpio-irqchip",
> + .irq_mask = irq_chip_mask_parent,
> + .irq_unmask = irq_chip_unmask_parent,
> + .irq_eoi = irq_chip_eoi_parent,
> + .irq_set_type = meson_gpio_irq_set_type,
> + .irq_retrigger = irq_chip_retrigger_hierarchy,
> +#ifdef CONFIG_SMP
> + .irq_set_affinity = irq_chip_set_affinity_parent,
> +#endif
> +};
> +
> +static int meson_gpio_irq_domain_translate(struct irq_domain *domain,
> + struct irq_fwspec *fwspec,
> + unsigned long *hwirq,
> + unsigned int *type)
> +{
> + if (is_of_node(fwspec->fwnode)) {
> + if (fwspec->param_count != 2)
> + return -EINVAL;
You can write this as:
if (is_of_node() && fwspec->... == 2) {
> +
> + *hwirq = fwspec->param[0];
> + *type = fwspec->param[1];
> +
> + return 0;
> + }
> +
> + return -EINVAL;
> +}
> +
> +static int meson_gpio_irq_allocate_gic_irq(struct irq_domain *domain,
> + unsigned int virq,
> + irq_hw_number_t source,
> + unsigned int type)
> +{
> + struct irq_fwspec fwspec;
> +
> + if (!irq_domain_get_of_node(domain->parent))
> + return -EINVAL;
How can you end-up here if the translate operation has failed?
> +
> + fwspec.fwnode = domain->parent->fwnode;
> + fwspec.param_count = 3;
> + fwspec.param[0] = 0; /* SPI */
> + fwspec.param[1] = source;
> + fwspec.param[2] = meson_gpio_irq_type_output(type);
> +
> + return irq_domain_alloc_irqs_parent(domain, virq, 1, &fwspec);
> +}
> +
> +static int meson_gpio_irq_domain_alloc(struct irq_domain *domain,
> + unsigned int virq,
> + unsigned int nr_irqs,
> + void *data)
> +{
> + struct irq_fwspec *fwspec = data;
> + struct meson_gpio_irq_domain *domain_data = domain->host_data;
> + struct meson_gpio_irq_chip_data *cd;
> + unsigned long hwirq, source;
> + unsigned int type;
> + int i, index, ret;
> +
> + ret = meson_gpio_irq_domain_translate(domain, fwspec, &hwirq, &type);
> + if (ret)
> + return ret;
> +
> + pr_debug("irq %d, nr_irqs %d, hwirqs %lu\n", virq, nr_irqs, hwirq);
> +
> + for (i = 0; i < nr_irqs; i++) {
This is a pattern that gets repeated over and over, for no good reason.
The only reason we have this nr_irqs thing is to handle things like
multi-MSI, where we have to *guarantee* that the hwirqs are allocated in
a contiguous manner.
Here, you don't enforce that guarantee, so you'd rather have a big fat:
if (WARN_ON(nr_irqs != 1))
return -EINVAL;
and get rid of that loop, because I cannot imagine a case where you'd
allocate more than a single interrupt@a time.
> + index = mesion_gpio_irq_map_source(domain_data, hwirq + i,
> + &source);
> + if (index < 0)
> + return index;
> +
> + ret = meson_gpio_irq_type_setup(type, domain_data->base,
> + index);
> + if (ret)
> + return ret;
Why do you have to to this here? This should be handled by the core code
already.
> +
> + cd = kzalloc(sizeof(*cd), GFP_KERNEL);
> + if (!cd)
> + return -ENOMEM;
> +
> + cd->base = domain_data->base;
> + cd->index = index;
So what is the exact purpose of this structure? The base address is
essentially a global, or could be directly derived from the domain. The
index is only used in set_type, and is the index of the pin connected to
the GIC. It looks to me like you could have:
irq_hw_number_t *out_line = &meson_parent_hwirqs[index];
> +
> + irq_domain_set_hwirq_and_chip(domain, virq + i, hwirq + i,
> + &meson_gpio_irq_chip, cd);
and this written as
irq_domain_set_hwirq_and_chip(domain, virq, hwirq,
out_line);
In your set_type function, you just compute the index back:
irq_hw_number_t *out_line = irq_data_get_irq_chip_data(data);
irq_hw_number_t index = out_line - meson_parent_hwirqs;
and you're done.
> +
> + ret = meson_gpio_irq_allocate_gic_irq(domain, virq + i,
> + source, type);
Resource leak on error.
> + if (ret < 0)
> + return ret;
> + }
> +
> + return 0;
> +}
> +
> +static void meson_gpio_irq_domain_free(struct irq_domain *domain,
> + unsigned int virq,
> + unsigned int nr_irqs)
> +{
> + struct meson_gpio_irq_domain *domain_data = domain->host_data;
> + struct meson_gpio_irq_chip_data *cd;
> + struct irq_data *irq_data;
> + int i;
> +
> + for (i = 0; i < nr_irqs; i++) {
Same comment as above.
> + irq_data = irq_domain_get_irq_data(domain, virq + i);
> + cd = irq_data_get_irq_chip_data(irq_data);
> +
> + domain_data->map[cd->index] = IRQ_FREE;
> + kfree(cd);
> + }
> +
> + irq_domain_free_irqs_parent(domain, virq, nr_irqs);
> +
> +}
> +
> +static const struct irq_domain_ops meson_gpio_irq_domain_ops = {
> + .alloc = meson_gpio_irq_domain_alloc,
> + .free = meson_gpio_irq_domain_free,
> + .translate = meson_gpio_irq_domain_translate,
> +};
> +
> +static int __init
> +meson_gpio_irq_init_domain(struct device_node *node,
> + struct meson_gpio_irq_domain *domain_data,
> + const struct meson_gpio_irq_params *params)
> +{
> + int i;
> + int nsource = params->nsource;
> + int *map;
> +
> + map = kcalloc(nsource, sizeof(*map), GFP_KERNEL);
> + if (!map)
> + return -ENOMEM;
> +
> + for (i = 0; i < nsource; i++)
> + map[i] = IRQ_FREE;
> +
> + domain_data->map = map;
You should now be able to kill most or all of this.
> + domain_data->params = params;
> +
> + return 0;
> +}
> +
> +static int __init meson_gpio_irq_of_init(struct device_node *node,
> + struct device_node *parent)
> +{
> + struct irq_domain *domain, *parent_domain;
> + const struct of_device_id *match;
> + const struct meson_gpio_irq_params *params;
> + struct meson_gpio_irq_domain *domain_data;
> + int ret;
> +
> + match = of_match_node(meson_irq_gpio_matches, node);
> + if (!match)
> + return -ENODEV;
> + params = match->data;
> +
> + if (!parent) {
> + pr_err("missing parent interrupt node\n");
> + return -ENODEV;
> + }
> +
> + parent_domain = irq_find_host(parent);
> + if (!parent_domain) {
> + pr_err("unable to obtain parent domain\n");
> + return -ENXIO;
> + }
> +
> + domain_data = kzalloc(sizeof(*domain_data), GFP_KERNEL);
> + if (!domain_data)
> + return -ENOMEM;
> +
> + domain_data->base = of_iomap(node, 0);
> + if (!domain_data->base) {
> + ret = -ENOMEM;
> + goto out_free_dev;
> + }
> +
> + ret = meson_gpio_irq_init_domain(node, domain_data, params);
> + if (ret < 0)
> + goto out_free_dev_content;
> +
> + domain = irq_domain_add_hierarchy(parent_domain, 0, params->nhwirq,
> + node, &meson_gpio_irq_domain_ops,
> + domain_data);
Please be consistent in using the fwnode API instead of the of_node one.
> +
> + if (!domain) {
> + pr_err("failed to allocated domain\n");
> + ret = -ENOMEM;
> + goto out_free_dev_content;
> + }
> +
> + pr_info("%d to %d gpio interrupt mux initialized\n",
> + params->nhwirq, params->nsource);
> +
> + return 0;
> +
> +out_free_dev_content:
> + kfree(domain_data->map);
> + iounmap(domain_data->base);
> +
> +out_free_dev:
> + kfree(domain_data);
> +
> + return ret;
> +}
> +
> +IRQCHIP_DECLARE(meson8_gpio_intc, "amlogic,meson8-gpio-intc",
> + meson_gpio_irq_of_init);
> +IRQCHIP_DECLARE(meson8b_gpio_intc, "amlogic,meson8b-gpio-intc",
> + meson_gpio_irq_of_init);
> +IRQCHIP_DECLARE(gxbb_gpio_intc, "amlogic,meson-gxbb-gpio-intc",
> + meson_gpio_irq_of_init);
>
Overall, this driver is a bit of a mess. Tons of structures that don't
make much sense, and a false sense of being able to support multiple
instances of the device.
I'll let Mark comment on the DT side of things.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH v2] ARM: bcm2835: Add names for the Raspberry Pi GPIO lines
From: Linus Walleij @ 2016-10-20 16:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPoCmYJC1TebBrspD_=mTETULSjg9or5a0Yda8p945y6ZWL99Q@mail.gmail.com>
On Tue, Oct 18, 2016 at 10:44 PM, Gottfried Haider
<gottfried.haider@gmail.com wrote:
> I'll hopefully find time to look at the more recent changes to the gpio
> subsystem (lsgpio?!), but since this patch is up for discussion now - what I
> was wondering: how does this change relate to /sys/class/gpio/gpio%d? Is
> this completely orthogonal - or would this change the sysfs interface as
> well?
The old sysfs interface is not changing. However it is deprecated so once
you have a v4.8+ kernel, consider migrating whatever userspace you have
to use the chardev ABI instead.
See:
commit fe95046e960b4b76e73dc1486955d93f47276134
"gpio: ABI: mark the sysfs ABI as obsolete"
commit 521a2ad6f862a28e2e43cb3e254a26bf0f9452e9
"gpio: add userspace ABI for GPIO line information"
commit d7c51b47ac11e66f547b55640405c1c474642d72
"gpio: userspace ABI for reading/writing GPIO lines"
commit 61f922db72216b00386581c851db9c9095961522
"gpio: userspace ABI for reading GPIO line events"
> Regarding the proposed format using the header pin numbers: From what I've
> seen in terms of existing educational materials, it seems the overwhelming
> majority ends up using GPIO numbers instead of physical pin header
> numbering. (e.g. [1] [2])
What does that number mean? If you are referring to the global
GPIO numberspace it is obsolete and just reflecting the fact that
people up until now was referring to Linux-internal GPIO numbers.
> Would it be too confusing to try to pick GPIO 5 from an alphabetically
> sorted list like this "P11_GPIO17", "P12_GPIO18"? (I know, alphabetical
> sorting is an issue here already for a different reason. But applications
> might do it, I guess?)
Any attempt to preserve the global GPIO numberspace is futile.
If it is the local offset number on the chip it is another thing, that
is kind of OK if the arch maintainer likes it.
Global GPIO numbers are inherently inconsistent since the introduction
of deferred probe, as GPIO drivers often pick a dynamic number base
and thus end up with the same number even though that can depend on
things like cosmic radiation or the temperature of their board when
they boot. So global GPIO numbers are considered harmful and have
therefore been obsoleted as userspace ABI.
Yours,
Linus Walleij
^ 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