* [PATCH v2 3/4] ARM64: dts: exynos5433: use macros for pinctrl configuration on Exynos5433
From: Krzysztof Kozlowski @ 2017-01-05 20:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbX_MuLSCerq08-1VZV6VJfynjkv1QOr7ssOCGvM5aB_Q@mail.gmail.com>
On Tue, Jan 03, 2017 at 09:24:34AM +0100, Linus Walleij wrote:
> On Fri, Dec 30, 2016 at 4:17 PM, Krzysztof Kozlowski <krzk@kernel.org> wrote:
> > On Fri, Dec 30, 2016 at 02:32:39PM +0100, Linus Walleij wrote:
> >> On Fri, Dec 30, 2016 at 5:14 AM, Andi Shyti <andi.shyti@samsung.com> wrote:
> >>
> >> > Use the macros defined in include/dt-bindings/pinctrl/samsung.h
> >> > instead of hardcoded values.
> >> >
> >> > Signed-off-by: Andi Shyti <andi.shyti@samsung.com>
> >>
> >> These look fine, but that this and the other DTS patch through ARM SoC.
> >>
> >> If you also need the headerfile patch (patch 2) to go through ARM SoC
> >> that is fine,
> >> I can take it out of pinctrl if you want.
> >
> > Yes, I need the header. It would be much appreciated if you could
> > provide a tag or stable branch with it.
>
> Nah better just merge that patch into the ARM SoC tree only.
>
> Acked-by: Linus Walleij <linus.walleij@linaro.org>
>
> I'll remove it from the pinctrl tree.
Thanks, I see it being dropped.
Andi,
Please fix missing Signed-off-by and resend with Linus' tags for #1 and
#2 and with other accumulated tags.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCHv2 4/5] arm: mvebu: Add device tree for 98DX3236 SoCs
From: Chris Packham @ 2017-01-05 20:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105135837.GC25333@leverpostej>
On 06/01/17 02:59, Mark Rutland wrote:
> On Thu, Jan 05, 2017 at 04:36:40PM +1300, Chris Packham wrote:
>> + internal-regs {
>> + coreclk: mvebu-sar at 18230 {
>> + compatible = "marvell,mv98dx3236-core-clock";
>> + };
>> +
>> + cpuclk: clock-complex at 18700 {
>> + compatible = "marvell,mv98dx3236-cpu-clock";
>> + };
>> +
>> + corediv-clock at 18740 {
>> + compatible = "marvell,mv98dx3236-corediv-clock";
>> + reg = <0xf8268 0xc>;
>> + base = <&dfx>;
>> + #clock-cells = <1>;
>> + clocks = <&mainpll>;
>> + clock-output-names = "nand";
>> + };
>
> [...]
>
>> + };
>> +
>> + dfx-registers {
>> + compatible = "simple-bus";
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + ranges = <0 MBUS_ID(0x08, 0x00) 0 0x100000>;
>> +
>> + dfx: dfx at 0 {
>> + compatible = "simple-bus";
>> + reg = <0 0x100000>;
>> + };
>> + };
>
> What is this dfx-registers, exactly?
I've been trying to get that info out of Marvell for a while I'm not
even sure what the "DFX" acronym stands for. The Armdada 38x also has a
thing called "DFX" but it seems to be quite different to this one. From
what I can tell it contains common elements used by both the CPU and
switch chip so there are things related to clocking and IO pad
configuration. It is necessary for both the switch and CPU to have a
handle to access it.
> It has no children, so why is it a
> simple-bus?
>
> From the above, and the patch adding the corediv driver, it looks like
> the corediv-clock actually lives in this block, so I don't understand
> why the corediv-clock is sitting in internal-regs with a sideband
> reference to dfx.
Yeah I think the corediv-clock should be a child of this node. I'll move
it there.
>
> Thanks,
> Mark.
>
^ permalink raw reply
* [PATCH 16/18] arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32
From: Yury Norov @ 2017-01-05 20:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3703608.GKr1zzErMk@wuerfel>
On Wed, Dec 07, 2016 at 09:40:13PM +0100, Arnd Bergmann wrote:
> On Wednesday, December 7, 2016 4:59:13 PM CET Catalin Marinas wrote:
> > On Tue, Dec 06, 2016 at 11:55:08AM +0530, Yury Norov wrote:
> > > On Mon, Dec 05, 2016 at 04:34:23PM +0000, Catalin Marinas wrote:
> > > > On Fri, Oct 21, 2016 at 11:33:15PM +0300, Yury Norov wrote:
> > > > > New aarch32 ptrace syscall handler is introduced to avoid run-time
> > > > > detection of the task type.
> > > >
> > > > What's wrong with the run-time detection? If it's just to avoid a
> > > > negligible overhead, I would rather keep the code simpler by avoiding
> > > > duplicating the generic compat_sys_ptrace().
> > >
> > > Nothing wrong. This is how Arnd asked me to do. You already asked this
> > > question: http://lkml.iu.edu/hypermail/linux/kernel/1604.3/00930.html
> >
> > Hmm, I completely forgot about this ;). There is still an advantage to
> > doing run-time checking if we avoid touching core code (less acks to
> > gather and less code duplication).
> >
> > Let's see what Arnd says but the initial patch looked simpler.
>
> I don't currently have either version of the patch in my inbox
> (the archive is on a different machine), but in general I'd still
> think it's best to avoid the runtime check for aarch64-ilp32
> altogether. I'd have to look at the overall kernel source to
> see if it's worth avoiding one or two instances though, or
> if there are an overwhelming number of other checks that we
> can't avoid at all.
>
> Regarding ptrace, I notice that arch/tile doesn't even use
> the compat entry point for its ilp32 user space on 64-bit
> kernels, it just calls the regular 64-bit one. Would that
> help here?
ILP32 tasks has unique context that is not like aarch64 or aarch32,
so we have to have unique ptrace handler. I prepared the patch for
ptrace with runtime ABI detection, as Catalin said, see there:
https://github.com/norov/linux/commit/1f66dc22a4450b192e83458f2c3cc0e79f53e670
If it's OK, I'd like to update submission.
Yury
^ permalink raw reply
* [PATCH] net: phy: dp83867: fix irq generation
From: Grygorii Strashko @ 2017-01-05 20:48 UTC (permalink / raw)
To: linux-arm-kernel
For proper IRQ generation by DP83867 phy the INT/PWDN pin has to be
programmed as an interrupt output instead of a Powerdown input in
Configuration Register 3 (CFG3), Address 0x001E, bit 7 INT_OE = 1. The
current driver doesn't do this and as result IRQs will not be generated by
DP83867 phy even if they are properly configured in DT.
Hence, fix IRQ generation by properly configuring CFG3.INT_OE bit and
ensure that Link Status Change (LINK_STATUS_CHNG_INT) and Auto-Negotiation
Complete (AUTONEG_COMP_INT) interrupt are enabled. After this the DP83867
driver will work properly in interrupt enabled mode.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
---
drivers/net/phy/dp83867.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index 1b63924..e84ae08 100644
--- a/drivers/net/phy/dp83867.c
+++ b/drivers/net/phy/dp83867.c
@@ -29,6 +29,7 @@
#define MII_DP83867_MICR 0x12
#define MII_DP83867_ISR 0x13
#define DP83867_CTRL 0x1f
+#define DP83867_CFG3 0x1e
/* Extended Registers */
#define DP83867_RGMIICTL 0x0032
@@ -98,6 +99,8 @@ static int dp83867_config_intr(struct phy_device *phydev)
micr_status |=
(MII_DP83867_MICR_AN_ERR_INT_EN |
MII_DP83867_MICR_SPEED_CHNG_INT_EN |
+ MII_DP83867_MICR_AUTONEG_COMP_INT_EN |
+ MII_DP83867_MICR_LINK_STS_CHNG_INT_EN |
MII_DP83867_MICR_DUP_MODE_CHNG_INT_EN |
MII_DP83867_MICR_SLEEP_MODE_CHNG_INT_EN);
@@ -214,6 +217,13 @@ static int dp83867_config_init(struct phy_device *phydev)
}
}
+ /* Enable Interrupt output INT_OE in CFG3 register */
+ if (phy_interrupt_is_valid(phydev)) {
+ val = phy_read(phydev, DP83867_CFG3);
+ val |= BIT(7);
+ phy_write(phydev, DP83867_CFG3, val);
+ }
+
return 0;
}
--
2.10.1.dirty
^ permalink raw reply related
* [PATCHv2 2/5] arm: mvebu: support for SMP on 98DX3336 SoC
From: Chris Packham @ 2017-01-05 20:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <dd384eda81d2420dafe740bf5bb4dae0@svr-chch-ex1.atlnz.lc>
On 05/01/17 17:46, Chris Packham wrote:
> On 05/01/17 17:04, Florian Fainelli wrote:
>> Le 01/04/17 ? 19:36, Chris Packham a ?crit :
>>> +}
>>> +
>>> +static int __init mv98dx3236_resume_init(void)
>>> +{
>>> + struct device_node *np;
>>> + struct resource res;
>>> + int ret = 0;
>>> +
>>> + np = of_find_matching_node(NULL, of_mv98dx3236_resume_table);
>>> + if (!np)
>>> + return 0;
>>
>> Can't this function be implemented as a smp_ops::smp_init_cpus instead
>> of having this initialization done at arch_initcall time?
>>
>
> I'll look into it. My initial reaction is no because I still need
> armada_xp_smp_init_cpus().
>
I looked at this. I could write a mv98dx3236_smp_init_cpus() that calls
armada_xp_smp_init_cpus() and inits the resume controller address. My
original reason for this approach was to parallel mvebu_v7_pmsu_init. I
won't do anything just yet but is there any downside to the current
approach?
^ permalink raw reply
* [PATCH v2] soc: ti: Drop wait from wkup_m3_rproc_boot_thread
From: Suman Anna @ 2017-01-05 21:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1483486889-3662-1-git-send-email-spjoshi@codeaurora.org>
On 01/03/2017 05:41 PM, Sarangdhar Joshi wrote:
> The function wkup_m3_rproc_boot_thread waits for
> asynchronous firmware loading to parse the resource table
> before calling rproc_boot(). However, as the resource table
> parsing has been moved to rproc_boot(), there's no need to
> wait for the asynchronous firmware loading completion.
> So, drop this.
>
> CC: Dave Gerlach <d-gerlach@ti.com>
> CC: Suman Anna <s-anna@ti.com>
> CC: Bjorn Andersson <bjorn.andersson@linaro.org>
> Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
+ Tony and Santosh, not sure who is picking up the wkup_m3 related patches.
Only one minor nit, I would prefer the patch subject to start with
soc: ti: wkup_m3_ipc: ....
Tested-by: Suman Anna <s-anna@ti.com>
regards
Suman
> ---
>
> This patch seems to be doing an independent clean up now. Hence
> removing it from the series.
>
> drivers/soc/ti/wkup_m3_ipc.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/soc/ti/wkup_m3_ipc.c b/drivers/soc/ti/wkup_m3_ipc.c
> index 8823cc8..8bfa44b 100644
> --- a/drivers/soc/ti/wkup_m3_ipc.c
> +++ b/drivers/soc/ti/wkup_m3_ipc.c
> @@ -370,8 +370,6 @@ static void wkup_m3_rproc_boot_thread(struct wkup_m3_ipc *m3_ipc)
> struct device *dev = m3_ipc->dev;
> int ret;
>
> - wait_for_completion(&m3_ipc->rproc->firmware_loading_complete);
> -
> init_completion(&m3_ipc->sync_complete);
>
> ret = rproc_boot(m3_ipc->rproc);
>
^ permalink raw reply
* [PATCH v2] soc: ti: Drop wait from wkup_m3_rproc_boot_thread
From: Santosh Shilimkar @ 2017-01-05 21:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <482666d0-7915-ead2-c514-2651a4967a43@ti.com>
On 1/5/2017 1:08 PM, Suman Anna wrote:
> On 01/03/2017 05:41 PM, Sarangdhar Joshi wrote:
>> The function wkup_m3_rproc_boot_thread waits for
>> asynchronous firmware loading to parse the resource table
>> before calling rproc_boot(). However, as the resource table
>> parsing has been moved to rproc_boot(), there's no need to
>> wait for the asynchronous firmware loading completion.
>> So, drop this.
>>
>> CC: Dave Gerlach <d-gerlach@ti.com>
>> CC: Suman Anna <s-anna@ti.com>
>> CC: Bjorn Andersson <bjorn.andersson@linaro.org>
>> Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
>
> + Tony and Santosh, not sure who is picking up the wkup_m3 related patches.
>
I think Tony has queued patches for wakeup_m3 before.
Regards,
Snatosh
^ permalink raw reply
* [PATCH V6 03/10] efi: parse ARM processor error
From: Baicar, Tyler @ 2017-01-05 21:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5852A3CA.807@arm.com>
On 12/15/2016 7:08 AM, James Morse wrote:
> Hi Tyler,
>
> On 07/12/16 21:48, Tyler Baicar wrote:
>> Add support for ARM Common Platform Error Record (CPER).
>> UEFI 2.6 specification adds support for ARM specific
>> processor error information to be reported as part of the
>> CPER records. This provides more detail on for processor error logs.
> Looks good to me, a few minor comments below.
>
> Reviewed-by: James Morse <james.morse@arm.com>
Thanks!
>> diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
>> index 8fa4e23..1ac2572 100644
>> --- a/drivers/firmware/efi/cper.c
>> +++ b/drivers/firmware/efi/cper.c
>> @@ -184,6 +199,110 @@ static void cper_print_proc_generic(const char *pfx,
>> printk("%s""IP: 0x%016llx\n", pfx, proc->ip);
>> }
>>
>> +static void cper_print_proc_arm(const char *pfx,
>> + const struct cper_sec_proc_arm *proc)
>> +{
>> + int i, len, max_ctx_type;
>> + struct cper_arm_err_info *err_info;
>> + struct cper_arm_ctx_info *ctx_info;
>> + char newpfx[64];
>> +
>> + printk("%ssection length: %d\n", pfx, proc->section_length);
> Compared to the rest of the file, this:
>> printk("%s""section length: %d\n", pfx, proc->section_length);
> would be more in keeping. I guess its done this way to avoid some spurious
> warning about %ssection not being recognised by printk().
Makes sense, I'll make this change next patchset.
>> + printk("%sMIDR: 0x%016llx\n", pfx, proc->midr);
>> +
>> + len = proc->section_length - (sizeof(*proc) +
>> + proc->err_info_num * (sizeof(*err_info)));
>> + if (len < 0) {
>> + printk("%ssection length is too small\n", pfx);
> This calculation is all based on values in the 'struct cper_sec_proc_arm', is it
> worth making more noise about how the firmware-generated record is incorrectly
> formatted? If we see this message its not the kernel's fault!
I can make the print more clear saying that the firmware-generated
record is incorrect to make
it clear it is not a kernel issue.
>> + printk("%sERR_INFO_NUM is %d\n", pfx, proc->err_info_num);
>> + return;
>> + }
>> +
>> + if (proc->validation_bits & CPER_ARM_VALID_MPIDR)
>> + printk("%sMPIDR: 0x%016llx\n", pfx, proc->mpidr);
>> + if (proc->validation_bits & CPER_ARM_VALID_AFFINITY_LEVEL)
>> + printk("%serror affinity level: %d\n", pfx,
>> + proc->affinity_level);
>> + if (proc->validation_bits & CPER_ARM_VALID_RUNNING_STATE) {
>> + printk("%srunning state: %d\n", pfx, proc->running_state);
> This field is described as a bit field in table 260, can we print it as 0x%lx in
> case additional bits are set?
Yes, will do.
>> + printk("%sPSCI state: %d\n", pfx, proc->psci_state);
>> + }
>> +
>> + snprintf(newpfx, sizeof(newpfx), "%s%s", pfx, INDENT_SP);
>> +
>> + err_info = (struct cper_arm_err_info *)(proc + 1);
>> + for (i = 0; i < proc->err_info_num; i++) {
>> + printk("%sError info structure %d:\n", pfx, i);
>> + printk("%sversion:%d\n", newpfx, err_info->version);
>> + printk("%slength:%d\n", newpfx, err_info->length);
>> + if (err_info->validation_bits &
>> + CPER_ARM_INFO_VALID_MULTI_ERR) {
>> + if (err_info->multiple_error == 0)
>> + printk("%ssingle error\n", newpfx);
>> + else if (err_info->multiple_error == 1)
>> + printk("%smultiple errors\n", newpfx);
>> + else
>> + printk("%smultiple errors count:%d\n",
>> + newpfx, err_info->multiple_error);
> This is described as unsigned in table 261.
Will change.
>> + }
>> + if (err_info->validation_bits & CPER_ARM_INFO_VALID_FLAGS) {
>> + if (err_info->flags & CPER_ARM_INFO_FLAGS_FIRST)
>> + printk("%sfirst error captured\n", newpfx);
>> + if (err_info->flags & CPER_ARM_INFO_FLAGS_LAST)
>> + printk("%slast error captured\n", newpfx);
>> + if (err_info->flags & CPER_ARM_INFO_FLAGS_PROPAGATED)
>> + printk("%spropagated error captured\n",
>> + newpfx);
> Table 261 also has an 'overflow' bit in flags. It may be worth printing a
> warning if this is set:
>> Note: Overflow bit indicates that firmware/hardware error
>> buffers had experience an overflow, and it is possible that
>> some error information has been lost.
I will add that in.
>> + }
>> + printk("%serror_type: %d, %s\n", newpfx, err_info->type,
>> + err_info->type < ARRAY_SIZE(proc_error_type_strs) ?
>> + proc_error_type_strs[err_info->type] : "unknown");
>> + if (err_info->validation_bits & CPER_ARM_INFO_VALID_ERR_INFO)
>> + printk("%serror_info: 0x%016llx\n", newpfx,
>> + err_info->error_info);
>> + if (err_info->validation_bits & CPER_ARM_INFO_VALID_VIRT_ADDR)
>> + printk("%svirtual fault address: 0x%016llx\n",
>> + newpfx, err_info->virt_fault_addr);
>> + if (err_info->validation_bits &
>> + CPER_ARM_INFO_VALID_PHYSICAL_ADDR)
>> + printk("%sphysical fault address: 0x%016llx\n",
>> + newpfx, err_info->physical_fault_addr);
>> + err_info += 1;
>> + }
>> + ctx_info = (struct cper_arm_ctx_info *)err_info;
>> + max_ctx_type = (sizeof(arm_reg_ctx_strs) /
>> + sizeof(arm_reg_ctx_strs[0]) - 1);
> ARRAY_SIZE() - 1?
I'll use ARRAY_SIZE in the next patchset.
>> + for (i = 0; i < proc->context_info_num; i++) {
>> + int size = sizeof(*ctx_info) + ctx_info->size;
>> +
>> + printk("%sContext info structure %d:\n", pfx, i);
>> + if (len < size) {
>> + printk("%ssection length is too small\n", newpfx);
>> + return;
>> + }
>> + if (ctx_info->type > max_ctx_type) {
>> + printk("%sInvalid context type: %d\n", newpfx,
>> + ctx_info->type);
>> + printk("%sMax context type: %d\n", newpfx,
>> + max_ctx_type);
>> + return;
>> + }
>> + printk("%sregister context type %d: %s\n", newpfx,
>> + ctx_info->type, arm_reg_ctx_strs[ctx_info->type]);
>> + print_hex_dump(newpfx, "", DUMP_PREFIX_OFFSET, 16, 4,
>> + (ctx_info + 1), ctx_info->size, 0);
>> + len -= size;
>> + ctx_info = (struct cper_arm_ctx_info *)((long)ctx_info + size);
>> + }
>> +
>> + if (len > 0) {
>> + printk("%sVendor specific error info has %d bytes:\n", pfx,
>> + len);
> %u - just in case it is surprisingly large!
>
Will do.
>> + print_hex_dump(newpfx, "", DUMP_PREFIX_OFFSET, 16, 4, ctx_info,
>> + len, 0);
>> + }
>> +}
>> +
>> static const char * const mem_err_type_strs[] = {
>> "unknown",
>> "no error",
>> @@ -458,6 +577,15 @@ static void cper_estatus_print_section(
>> cper_print_pcie(newpfx, pcie, gdata);
>> else
>> goto err_section_too_small;
>> + } else if (!uuid_le_cmp(*sec_type, CPER_SEC_PROC_ARM)) {
>> + struct cper_sec_proc_arm *arm_err;
>> +
>> + arm_err = acpi_hest_generic_data_payload(gdata);
>> + printk("%ssection_type: ARM processor error\n", newpfx);
>> + if (gdata->error_data_length >= sizeof(*arm_err))
>> + cper_print_proc_arm(newpfx, arm_err);
>> + else
>> + goto err_section_too_small;
>> } else
>> printk("%s""section type: unknown, %pUl\n", newpfx, sec_type);
>>
> This is the only processor-specific entry in this function,
> CPER_SEC_PROC_{IA,IPF} don't appear anywhere else in the tree.
>
> Is it worth adding an (IS_ENABLED(CONFIG_ARM64) || IS_ENABLED(CONFIG_ARM)) in
> the if()? This would let the compiler remove cper_print_proc_arm(() on x86/ia64
> systems which won't ever see a record of this type.
Yes, I can add that.
Thank you for the feedback!
-Tyler
--
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 2/2] isdn: i4l: move active-isdn drivers to staging
From: Greg Kroah-Hartman @ 2017-01-05 21:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3286019.I2UkVCJq41@wuerfel>
On Tue, Jan 03, 2017 at 10:19:29PM +0100, Arnd Bergmann wrote:
> On Tuesday, January 3, 2017 4:24:36 PM CET Greg Kroah-Hartman wrote:
> > On Wed, Mar 02, 2016 at 08:06:46PM +0100, Arnd Bergmann wrote:
> > > The icn, act2000 and pcbit drivers are all for very old hardware,
> > > and it is highly unlikely that anyone is actually still using them
> > > on modern kernels, if at all.
> > >
> > > All three drivers apparently are for hardware that predates PCI
> > > being the common connector, as they are ISA-only and active
> > > PCI ISDN cards were widely available in the 1990s.
> > >
> > > Looking through the git logs, it I cannot find any indication of a
> > > patch to any of these drivers that has been tested on real hardware,
> > > only cleanups or global API changes.
> > >
> > > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > > Acked-by: Karsten Keil <isdn@linux-pingi.de>
> >
> > This patch got added in the 4.6 kernel release. As I am now taking
> > patches for 4.11-rc1, I figure it is time to just delete the
> > drivers/staging/i4l/ directory now, given that no one has really done
> > anything with it. If people show up that wish to maintain it, I'll be
> > glad to revert it, or if someone really screams in the next week.
> > Otherwise it's time to just move on
>
> Sounds good to me.
Ok, now deleted!
thanks,
greg k-h
^ permalink raw reply
* [PATCH] MAINTAINERS: Add Aaro Koskinen as TI omap1 SoC co-maintainer
From: Tony Lindgren @ 2017-01-05 21:41 UTC (permalink / raw)
To: linux-arm-kernel
Aaro has been doing a great job making sure mach-omap1 stays working
with the mainline kernel. So let's add Aaro as omap1 co-maintainer to
the MAINTAINERS file.
Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
MAINTAINERS | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8933,7 +8933,20 @@ M: Josh Poimboeuf <jpoimboe@redhat.com>
S: Supported
F: tools/objtool/
-OMAP SUPPORT
+OMAP1 SUPPORT
+M: Aaro Koskinen <aaro.koskinen@iki.fi>
+M: Tony Lindgren <tony@atomide.com>
+L: linux-omap at vger.kernel.org
+Q: http://patchwork.kernel.org/project/linux-omap/list/
+T: git git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
+S: Maintained
+F: arch/arm/mach-omap1/
+F: arch/arm/plat-omap/
+F: arch/arm/configs/omap1_defconfig
+F: drivers/i2c/busses/i2c-omap.c
+F: include/linux/i2c-omap.h
+
+OMAP2+ SUPPORT
M: Tony Lindgren <tony@atomide.com>
L: linux-omap at vger.kernel.org
W: http://www.muru.com/linux/omap/
@@ -8941,8 +8954,8 @@ W: http://linux.omap.com/
Q: http://patchwork.kernel.org/project/linux-omap/list/
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
S: Maintained
-F: arch/arm/*omap*/
-F: arch/arm/configs/omap1_defconfig
+F: arch/arm/mach-omap2/
+F: arch/arm/plat-omap/
F: arch/arm/configs/omap2plus_defconfig
F: drivers/i2c/busses/i2c-omap.c
F: drivers/irqchip/irq-omap-intc.c
--
2.11.0
^ permalink raw reply
* [PATCH] ARM: OMAP1: DMA: Correct the number of logical channels
From: Aaro Koskinen @ 2017-01-05 21:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170103112234.19097-1-peter.ujfalusi@ti.com>
Hi,
On Tue, Jan 03, 2017 at 01:22:34PM +0200, Peter Ujfalusi wrote:
> OMAP1510, OMAP5910 and OMAP310 have only 9 logical channels.
> OMAP1610, OMAP5912, OMAP1710, OMAP730, and OMAP850 have 16 logical channels
> available.
>
> The wired 17 for the lch_count must have been used to cover the 16 + 1
> dedicated LCD channel, in reality we can only use 9 or 16 channels.
>
> The d->chan_count is not used by the omap-dma stack, so we can skip the
> setup. chan_count was configured to the number of logical channels and not
> the actual number of physical channels anyways.
>
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi>
A.
> ---
> arch/arm/mach-omap1/dma.c | 16 +++++++---------
> 1 file changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/arch/arm/mach-omap1/dma.c b/arch/arm/mach-omap1/dma.c
> index f6ba589cd312..c821c1d5610e 100644
> --- a/arch/arm/mach-omap1/dma.c
> +++ b/arch/arm/mach-omap1/dma.c
> @@ -32,7 +32,6 @@
> #include "soc.h"
>
> #define OMAP1_DMA_BASE (0xfffed800)
> -#define OMAP1_LOGICAL_DMA_CH_COUNT 17
>
> static u32 enable_1510_mode;
>
> @@ -348,8 +347,6 @@ static int __init omap1_system_dma_init(void)
> goto exit_iounmap;
> }
>
> - d->lch_count = OMAP1_LOGICAL_DMA_CH_COUNT;
> -
> /* Valid attributes for omap1 plus processors */
> if (cpu_is_omap15xx())
> d->dev_caps = ENABLE_1510_MODE;
> @@ -366,13 +363,14 @@ static int __init omap1_system_dma_init(void)
> d->dev_caps |= CLEAR_CSR_ON_READ;
> d->dev_caps |= IS_WORD_16;
>
> - if (cpu_is_omap15xx())
> - d->chan_count = 9;
> - else if (cpu_is_omap16xx() || cpu_is_omap7xx()) {
> - if (!(d->dev_caps & ENABLE_1510_MODE))
> - d->chan_count = 16;
> + /* available logical channels */
> + if (cpu_is_omap15xx()) {
> + d->lch_count = 9;
> + } else {
> + if (d->dev_caps & ENABLE_1510_MODE)
> + d->lch_count = 9;
> else
> - d->chan_count = 9;
> + d->lch_count = 16;
> }
>
> p = dma_plat_info;
> --
> 2.11.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" 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] MAINTAINERS: Add Aaro Koskinen as TI omap1 SoC co-maintainer
From: Aaro Koskinen @ 2017-01-05 21:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105214101.30286-1-tony@atomide.com>
Hi,
On Thu, Jan 05, 2017 at 01:41:01PM -0800, Tony Lindgren wrote:
> Aaro has been doing a great job making sure mach-omap1 stays working
> with the mainline kernel. So let's add Aaro as omap1 co-maintainer to
> the MAINTAINERS file.
>
> Cc: Aaro Koskinen <aaro.koskinen@iki.fi>
> Signed-off-by: Tony Lindgren <tony@atomide.com>
Acked-by: Aaro Koskinen <aaro.koskinen@iki.fi>
A.
> ---
> MAINTAINERS | 19 ++++++++++++++++---
> 1 file changed, 16 insertions(+), 3 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8933,7 +8933,20 @@ M: Josh Poimboeuf <jpoimboe@redhat.com>
> S: Supported
> F: tools/objtool/
>
> -OMAP SUPPORT
> +OMAP1 SUPPORT
> +M: Aaro Koskinen <aaro.koskinen@iki.fi>
> +M: Tony Lindgren <tony@atomide.com>
> +L: linux-omap at vger.kernel.org
> +Q: http://patchwork.kernel.org/project/linux-omap/list/
> +T: git git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
> +S: Maintained
> +F: arch/arm/mach-omap1/
> +F: arch/arm/plat-omap/
> +F: arch/arm/configs/omap1_defconfig
> +F: drivers/i2c/busses/i2c-omap.c
> +F: include/linux/i2c-omap.h
> +
> +OMAP2+ SUPPORT
> M: Tony Lindgren <tony@atomide.com>
> L: linux-omap at vger.kernel.org
> W: http://www.muru.com/linux/omap/
> @@ -8941,8 +8954,8 @@ W: http://linux.omap.com/
> Q: http://patchwork.kernel.org/project/linux-omap/list/
> T: git git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap.git
> S: Maintained
> -F: arch/arm/*omap*/
> -F: arch/arm/configs/omap1_defconfig
> +F: arch/arm/mach-omap2/
> +F: arch/arm/plat-omap/
> F: arch/arm/configs/omap2plus_defconfig
> F: drivers/i2c/busses/i2c-omap.c
> F: drivers/irqchip/irq-omap-intc.c
> --
> 2.11.0
^ permalink raw reply
* [PATCH v2] soc: ti: Drop wait from wkup_m3_rproc_boot_thread
From: Sarangdhar Joshi @ 2017-01-05 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <482666d0-7915-ead2-c514-2651a4967a43@ti.com>
On 01/05/2017 01:08 PM, Suman Anna wrote:
> On 01/03/2017 05:41 PM, Sarangdhar Joshi wrote:
>> The function wkup_m3_rproc_boot_thread waits for
>> asynchronous firmware loading to parse the resource table
>> before calling rproc_boot(). However, as the resource table
>> parsing has been moved to rproc_boot(), there's no need to
>> wait for the asynchronous firmware loading completion.
>> So, drop this.
>>
>> CC: Dave Gerlach <d-gerlach@ti.com>
>> CC: Suman Anna <s-anna@ti.com>
>> CC: Bjorn Andersson <bjorn.andersson@linaro.org>
>> Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
>
> + Tony and Santosh, not sure who is picking up the wkup_m3 related patches.
>
> Only one minor nit, I would prefer the patch subject to start with
> soc: ti: wkup_m3_ipc: ....
Sure, will update the subject line.
Regards,
Sarang
>
> Tested-by: Suman Anna <s-anna@ti.com>
>
> regards
> Suman
>
>> ---
>>
>> This patch seems to be doing an independent clean up now. Hence
>> removing it from the series.
>>
>> drivers/soc/ti/wkup_m3_ipc.c | 2 --
>> 1 file changed, 2 deletions(-)
>>
>> diff --git a/drivers/soc/ti/wkup_m3_ipc.c b/drivers/soc/ti/wkup_m3_ipc.c
>> index 8823cc8..8bfa44b 100644
>> --- a/drivers/soc/ti/wkup_m3_ipc.c
>> +++ b/drivers/soc/ti/wkup_m3_ipc.c
>> @@ -370,8 +370,6 @@ static void wkup_m3_rproc_boot_thread(struct wkup_m3_ipc *m3_ipc)
>> struct device *dev = m3_ipc->dev;
>> int ret;
>>
>> - wait_for_completion(&m3_ipc->rproc->firmware_loading_complete);
>> -
>> init_completion(&m3_ipc->sync_complete);
>>
>> ret = rproc_boot(m3_ipc->rproc);
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v3] soc: ti: wkup_m3_ipc: Drop wait from wkup_m3_rproc_boot_thread
From: Sarangdhar Joshi @ 2017-01-05 22:00 UTC (permalink / raw)
To: linux-arm-kernel
The function wkup_m3_rproc_boot_thread waits for asynchronous
firmware loading to parse the resource table before calling
rproc_boot(). However, as the resource table parsing has been
moved to rproc_boot(), there's no need to wait for the
asynchronous firmware loading completion. So, drop this.
CC: Dave Gerlach <d-gerlach@ti.com>
CC: Bjorn Andersson <bjorn.andersson@linaro.org>
Tested-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
---
This patch seems to be doing an independent clean up now. Hence
removing it from the series.
Changes from v2:
* Updated the subject line as per Suman's comment
drivers/soc/ti/wkup_m3_ipc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/soc/ti/wkup_m3_ipc.c b/drivers/soc/ti/wkup_m3_ipc.c
index 8823cc8..8bfa44b 100644
--- a/drivers/soc/ti/wkup_m3_ipc.c
+++ b/drivers/soc/ti/wkup_m3_ipc.c
@@ -370,8 +370,6 @@ static void wkup_m3_rproc_boot_thread(struct wkup_m3_ipc *m3_ipc)
struct device *dev = m3_ipc->dev;
int ret;
- wait_for_completion(&m3_ipc->rproc->firmware_loading_complete);
-
init_completion(&m3_ipc->sync_complete);
ret = rproc_boot(m3_ipc->rproc);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH v2] soc: ti: Drop wait from wkup_m3_rproc_boot_thread
From: Tony Lindgren @ 2017-01-05 22:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d98575a9-1863-88f0-d417-ae894db2dc55@oracle.com>
* Santosh Shilimkar <santosh.shilimkar@oracle.com> [170105 13:18]:
>
>
> On 1/5/2017 1:08 PM, Suman Anna wrote:
> > On 01/03/2017 05:41 PM, Sarangdhar Joshi wrote:
> > > The function wkup_m3_rproc_boot_thread waits for
> > > asynchronous firmware loading to parse the resource table
> > > before calling rproc_boot(). However, as the resource table
> > > parsing has been moved to rproc_boot(), there's no need to
> > > wait for the asynchronous firmware loading completion.
> > > So, drop this.
> > >
> > > CC: Dave Gerlach <d-gerlach@ti.com>
> > > CC: Suman Anna <s-anna@ti.com>
> > > CC: Bjorn Andersson <bjorn.andersson@linaro.org>
> > > Signed-off-by: Sarangdhar Joshi <spjoshi@codeaurora.org>
> >
> > + Tony and Santosh, not sure who is picking up the wkup_m3 related patches.
> >
> I think Tony has queued patches for wakeup_m3 before.
Sure I can queue it.
Thanks,
Tony
^ permalink raw reply
* [PATCH 3/6] clk: sunxi-ng: Add H5 clocks
From: Maxime Ripard @ 2017-01-05 22:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161226162518.5367-4-icenowy@aosc.xyz>
On Tue, Dec 27, 2016 at 12:25:15AM +0800, Icenowy Zheng wrote:
> Add the H5 CCU clocks set based on the H3 one.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
Is there any difference with H3's?
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/20170105/c4135864/attachment.sig>
^ permalink raw reply
* [PATCH 1/6] drivers: pinctrl: add driver for Allwinner H5 SoC
From: Maxime Ripard @ 2017-01-05 22:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161226162518.5367-2-icenowy@aosc.xyz>
On Tue, Dec 27, 2016 at 12:25:13AM +0800, Icenowy Zheng wrote:
> Based on the Allwinner H5 datasheet and the pinctrl driver of the
> backward-compatible H3 this introduces the pin multiplex assignments for
> the H5 SoC.
>
> H5 introduced some more pin functions (e.g. three more groups of TS
> pins, and one more groups of SIM pins) than H3.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> ---
> .../bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 1 +
> drivers/pinctrl/sunxi/Kconfig | 4 +
> drivers/pinctrl/sunxi/Makefile | 1 +
> drivers/pinctrl/sunxi/pinctrl-sun50i-h5.c | 551 +++++++++++++++++++++
> 4 files changed, 557 insertions(+)
> create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun50i-h5.c
>
> diff --git a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> index c931fb1c01a6..2fd688c8dbdb 100644
> --- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> +++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
> @@ -23,6 +23,7 @@ Required properties:
> "allwinner,sun8i-h3-pinctrl"
> "allwinner,sun8i-h3-r-pinctrl"
> "allwinner,sun50i-a64-pinctrl"
> + "allwinner,sun50i-h5-r-pinctrl"
You're using a different compatible in your driver.
> "nextthing,gr8-pinctrl"
>
> - reg: Should contain the register physical address and length for the
> diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
> index bff1ffc6f01e..e9c47e8b2ee0 100644
> --- a/drivers/pinctrl/sunxi/Kconfig
> +++ b/drivers/pinctrl/sunxi/Kconfig
> @@ -76,4 +76,8 @@ config PINCTRL_SUN50I_A64
> bool
> select PINCTRL_SUNXI
>
> +config PINCTRL_SUN50I_H5
> + bool
> + select PINCTRL_SUNXI
> +
> endif
> diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
> index 95f93d0561fc..bab215d25440 100644
> --- a/drivers/pinctrl/sunxi/Makefile
> +++ b/drivers/pinctrl/sunxi/Makefile
> @@ -17,5 +17,6 @@ obj-$(CONFIG_PINCTRL_SUN50I_A64) += pinctrl-sun50i-a64.o
> obj-$(CONFIG_PINCTRL_SUN8I_A83T) += pinctrl-sun8i-a83t.o
> obj-$(CONFIG_PINCTRL_SUN8I_H3) += pinctrl-sun8i-h3.o
> obj-$(CONFIG_PINCTRL_SUN8I_H3_R) += pinctrl-sun8i-h3-r.o
> +obj-$(CONFIG_PINCTRL_SUN50I_H5) += pinctrl-sun50i-h5.o
> obj-$(CONFIG_PINCTRL_SUN9I_A80) += pinctrl-sun9i-a80.o
> obj-$(CONFIG_PINCTRL_SUN9I_A80_R) += pinctrl-sun9i-a80-r.o
> diff --git a/drivers/pinctrl/sunxi/pinctrl-sun50i-h5.c b/drivers/pinctrl/sunxi/pinctrl-sun50i-h5.c
> new file mode 100644
> index 000000000000..67a55df37782
> --- /dev/null
> +++ b/drivers/pinctrl/sunxi/pinctrl-sun50i-h5.c
> @@ -0,0 +1,551 @@
> +/*
> + * Allwinner H5 SoC pinctrl driver.
> + *
> + * Copyright (C) 2016 Icenowy Zheng <icenowy@aosc.xyz>
> + *
> + * Based on pinctrl-sun8i-h3.c, which is:
> + * Copyright (C) 2015 Jens Kuske <jenskuske@gmail.com>
> + *
> + * Based on pinctrl-sun8i-a23.c, which is:
> + * Copyright (C) 2014 Chen-Yu Tsai <wens@csie.org>
> + * Copyright (C) 2014 Maxime Ripard <maxime.ripard@free-electrons.com>
> + *
> + * This file is licensed under the terms of the GNU General Public
> + * License version 2. This program is licensed "as is" without any
> + * warranty of any kind, whether express or implied.
> + */
> +
> +#include <linux/module.h>
> +#include <linux/platform_device.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
> +#include <linux/pinctrl/pinctrl.h>
> +
> +#include "pinctrl-sunxi.h"
> +
> +static const struct sunxi_desc_pin sun50i_h5_pins[] = {
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart2"), /* TX */
> + SUNXI_FUNCTION(0x3, "jtag"), /* MS */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)), /* PA_EINT0 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart2"), /* RX */
> + SUNXI_FUNCTION(0x3, "jtag"), /* CK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 1)), /* PA_EINT1 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart2"), /* RTS */
> + SUNXI_FUNCTION(0x3, "jtag"), /* DO */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 2)), /* PA_EINT2 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 3),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart2"), /* CTS */
> + SUNXI_FUNCTION(0x3, "jtag"), /* DI */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 3)), /* PA_EINT3 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 4),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart0"), /* TX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 4)), /* PA_EINT4 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 5),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart0"), /* RX */
> + SUNXI_FUNCTION(0x3, "pwm0"),
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 5)), /* PA_EINT5 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 6),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "sim"), /* PWREN */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 6)), /* PA_EINT6 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 7),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "sim"), /* CLK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 7)), /* PA_EINT7 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 8),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "sim"), /* DATA */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 8)), /* PA_EINT8 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 9),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "sim"), /* RST */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 9)), /* PA_EINT9 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 10),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "sim"), /* DET */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 10)), /* PA_EINT10 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 11),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2c0"), /* SCK */
> + SUNXI_FUNCTION(0x3, "di"), /* TX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 11)), /* PA_EINT11 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 12),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2c0"), /* SDA */
> + SUNXI_FUNCTION(0x3, "di"), /* RX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 12)), /* PA_EINT12 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 13),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "spi1"), /* CS */
> + SUNXI_FUNCTION(0x3, "uart3"), /* TX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 13)), /* PA_EINT13 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 14),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "spi1"), /* CLK */
> + SUNXI_FUNCTION(0x3, "uart3"), /* RX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 14)), /* PA_EINT14 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 15),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "spi1"), /* MOSI */
> + SUNXI_FUNCTION(0x3, "uart3"), /* RTS */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 15)), /* PA_EINT15 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 16),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "spi1"), /* MISO */
> + SUNXI_FUNCTION(0x3, "uart3"), /* CTS */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 16)), /* PA_EINT16 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 17),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "spdif"), /* OUT */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 17)), /* PA_EINT17 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 18),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2s0"), /* SYNC */
> + SUNXI_FUNCTION(0x3, "i2c1"), /* SCK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 18)), /* PA_EINT18 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 19),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2s0"), /* CLK */
> + SUNXI_FUNCTION(0x3, "i2c1"), /* SDA */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 19)), /* PA_EINT19 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 20),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2s0"), /* DOUT */
> + SUNXI_FUNCTION(0x3, "sim"), /* VPPEN */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 20)), /* PA_EINT20 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 21),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2s0"), /* DIN */
> + SUNXI_FUNCTION(0x3, "sim"), /* VPPPP */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 21)), /* PA_EINT21 */
> + /* Hole */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* WE */
> + SUNXI_FUNCTION(0x3, "spi0")), /* MOSI */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* ALE */
> + SUNXI_FUNCTION(0x3, "spi0"), /* MISO */
> + SUNXI_FUNCTION(0x4, "mmc2")), /* DS */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* CLE */
> + SUNXI_FUNCTION(0x3, "spi0")), /* CLK */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 3),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* CE1 */
> + SUNXI_FUNCTION(0x3, "spi0")), /* CS */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 4),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* CE0 */
> + SUNXI_FUNCTION(0x4, "spi0")), /* MISO */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 5),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* RE */
> + SUNXI_FUNCTION(0x3, "mmc2")), /* CLK */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 6),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* RB0 */
> + SUNXI_FUNCTION(0x3, "mmc2")), /* CMD */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 7),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0")), /* RB1 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 8),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ0 */
> + SUNXI_FUNCTION(0x3, "mmc2")), /* D0 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 9),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ1 */
> + SUNXI_FUNCTION(0x3, "mmc2")), /* D1 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 10),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ2 */
> + SUNXI_FUNCTION(0x3, "mmc2")), /* D2 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 11),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ3 */
> + SUNXI_FUNCTION(0x3, "mmc2")), /* D3 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 12),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ4 */
> + SUNXI_FUNCTION(0x3, "mmc2")), /* D4 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 13),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ5 */
> + SUNXI_FUNCTION(0x3, "mmc2")), /* D5 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 14),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ6 */
> + SUNXI_FUNCTION(0x3, "mmc2")), /* D6 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 15),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQ7 */
> + SUNXI_FUNCTION(0x3, "mmc2")), /* D7 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 16),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "nand0"), /* DQS */
> + SUNXI_FUNCTION(0x3, "mmc2")), /* RST */
> + /* Hole */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac"), /* RXD3 */
> + SUNXI_FUNCTION(0x3, "di"), /* TX */
> + SUNXI_FUNCTION(0x4, "ts2")), /* CLK */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac"), /* RXD2 */
> + SUNXI_FUNCTION(0x3, "di"), /* RX */
> + SUNXI_FUNCTION(0x4, "ts2")), /* ERR */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac"), /* RXD1 */
> + SUNXI_FUNCTION(0x4, "ts2")), /* SYNC */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 3),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac"), /* RXD0 */
> + SUNXI_FUNCTION(0x4, "ts2")), /* DVLD */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 4),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac"), /* RXCK */
> + SUNXI_FUNCTION(0x4, "ts2")), /* D0 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 5),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac"), /* RXCTL/RXDV */
> + SUNXI_FUNCTION(0x4, "ts2")), /* D1 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 6),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac"), /* RXERR */
> + SUNXI_FUNCTION(0x4, "ts2")), /* D2 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 7),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac"), /* TXD3 */
> + SUNXI_FUNCTION(0x4, "ts2"), /* D3 */
> + SUNXI_FUNCTION(0x5, "ts3")), /* CLK */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 8),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac"), /* TXD2 */
> + SUNXI_FUNCTION(0x4, "ts2"), /* D4 */
> + SUNXI_FUNCTION(0x5, "ts3")), /* ERR */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 9),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac"), /* TXD1 */
> + SUNXI_FUNCTION(0x4, "ts2"), /* D5 */
> + SUNXI_FUNCTION(0x5, "ts3")), /* SYNC */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 10),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac"), /* TXD0 */
> + SUNXI_FUNCTION(0x4, "ts2"), /* D6 */
> + SUNXI_FUNCTION(0x5, "ts3")), /* DVLD */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 11),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac"), /* CRS */
> + SUNXI_FUNCTION(0x4, "ts2"), /* D7 */
> + SUNXI_FUNCTION(0x5, "ts3")), /* D0 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 12),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac"), /* TXCK */
> + SUNXI_FUNCTION(0x4, "sim")), /* PWREN */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 13),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac"), /* TXCTL/TXEN */
> + SUNXI_FUNCTION(0x4, "sim")), /* CLK */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 14),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac"), /* TXERR */
> + SUNXI_FUNCTION(0x4, "sim")), /* DATA */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 15),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac"), /* CLKIN/COL */
> + SUNXI_FUNCTION(0x4, "sim")), /* RST */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 16),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac"), /* MDC */
> + SUNXI_FUNCTION(0x4, "sim")), /* DET */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(D, 17),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "emac")), /* MDIO */
> + /* Hole */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "csi"), /* PCLK */
> + SUNXI_FUNCTION(0x3, "ts0")), /* CLK */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "csi"), /* MCLK */
> + SUNXI_FUNCTION(0x3, "ts0")), /* ERR */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "csi"), /* HSYNC */
> + SUNXI_FUNCTION(0x3, "ts0")), /* SYNC */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 3),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "csi"), /* VSYNC */
> + SUNXI_FUNCTION(0x3, "ts0")), /* DVLD */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 4),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "csi"), /* D0 */
> + SUNXI_FUNCTION(0x3, "ts0")), /* D0 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 5),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "csi"), /* D1 */
> + SUNXI_FUNCTION(0x3, "ts0")), /* D1 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 6),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "csi"), /* D2 */
> + SUNXI_FUNCTION(0x3, "ts0")), /* D2 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 7),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "csi"), /* D3 */
> + SUNXI_FUNCTION(0x3, "ts0"), /* D3 */
> + SUNXI_FUNCTION(0x4, "ts1")), /* CLK */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 8),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "csi"), /* D4 */
> + SUNXI_FUNCTION(0x3, "ts0"), /* D4 */
> + SUNXI_FUNCTION(0x4, "ts1")), /* ERR */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 9),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "csi"), /* D5 */
> + SUNXI_FUNCTION(0x3, "ts0"), /* D5 */
> + SUNXI_FUNCTION(0x4, "ts1")), /* SYNC */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 10),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "csi"), /* D6 */
> + SUNXI_FUNCTION(0x3, "ts0"), /* D6 */
> + SUNXI_FUNCTION(0x4, "ts1")), /* DVLD */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 11),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "csi"), /* D7 */
> + SUNXI_FUNCTION(0x3, "ts"), /* D7 */
> + SUNXI_FUNCTION(0x4, "ts1")), /* D0 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 12),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "csi"), /* SCK */
> + SUNXI_FUNCTION(0x3, "i2c2")), /* SCK */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 13),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "csi"), /* SDA */
> + SUNXI_FUNCTION(0x3, "i2c2")), /* SDA */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 14),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "sim")), /* VPPEN */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(E, 15),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x3, "sim")), /* VPPPP */
> + /* Hole */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc0"), /* D1 */
> + SUNXI_FUNCTION(0x3, "jtag")), /* MS */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc0"), /* D0 */
> + SUNXI_FUNCTION(0x3, "jtag")), /* DI */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc0"), /* CLK */
> + SUNXI_FUNCTION(0x3, "uart0")), /* TX */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 3),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc0"), /* CMD */
> + SUNXI_FUNCTION(0x3, "jtag")), /* DO */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 4),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc0"), /* D3 */
> + SUNXI_FUNCTION(0x3, "uart0")), /* RX */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 5),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc0"), /* D2 */
> + SUNXI_FUNCTION(0x3, "jtag")), /* CK */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(F, 6),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out")),
> + /* Hole */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 0),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc1"), /* CLK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 0)), /* PG_EINT0 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 1),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc1"), /* CMD */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 1)), /* PG_EINT1 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 2),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc1"), /* D0 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 2)), /* PG_EINT2 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 3),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc1"), /* D1 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 3)), /* PG_EINT3 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 4),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc1"), /* D2 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 4)), /* PG_EINT4 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 5),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "mmc1"), /* D3 */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 5)), /* PG_EINT5 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 6),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart1"), /* TX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 6)), /* PG_EINT6 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 7),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart1"), /* RX */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 7)), /* PG_EINT7 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 8),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart1"), /* RTS */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 8)), /* PG_EINT8 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 9),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "uart1"), /* CTS */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 9)), /* PG_EINT9 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 10),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2s1"), /* SYNC */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 10)), /* PG_EINT10 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 11),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2s1"), /* CLK */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 11)), /* PG_EINT11 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 12),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2s1"), /* DOUT */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 12)), /* PG_EINT12 */
> + SUNXI_PIN(SUNXI_PINCTRL_PIN(G, 13),
> + SUNXI_FUNCTION(0x0, "gpio_in"),
> + SUNXI_FUNCTION(0x1, "gpio_out"),
> + SUNXI_FUNCTION(0x2, "i2s1"), /* DIN */
> + SUNXI_FUNCTION_IRQ_BANK(0x6, 1, 13)), /* PG_EINT13 */
> +};
> +
> +static const struct sunxi_pinctrl_desc sun50i_h5_pinctrl_data = {
> + .pins = sun50i_h5_pins,
> + .npins = ARRAY_SIZE(sun50i_h5_pins),
> + .irq_banks = 2,
> + .irq_read_needs_mux = true
> +};
> +
> +static int sun50i_h5_pinctrl_probe(struct platform_device *pdev)
> +{
> + return sunxi_pinctrl_init(pdev,
> + &sun50i_h5_pinctrl_data);
> +}
> +
> +static const struct of_device_id sun50i_h5_pinctrl_match[] = {
> + { .compatible = "allwinner,sun50i-h5-pinctrl", },
> + {}
> +};
> +
> +static struct platform_driver sun50i_h5_pinctrl_driver = {
> + .probe = sun50i_h5_pinctrl_probe,
> + .driver = {
> + .name = "sun50i-h5-pinctrl",
> + .of_match_table = sun50i_h5_pinctrl_match,
> + },
> +};
> +builtin_platform_driver(sun50i_h5_pinctrl_driver);
This also looks very much like the H3. I'll post a patchset during the
weekend to avoid duplicating those drivers. This was initially done
for the sun5i, but it very much applies here.
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/20170105/ebb21db0/attachment-0001.sig>
^ permalink raw reply
* [PATCH] net: phy: dp83867: fix irq generation
From: Florian Fainelli @ 2017-01-05 22:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105204807.25990-1-grygorii.strashko@ti.com>
On 01/05/2017 12:48 PM, Grygorii Strashko wrote:
> For proper IRQ generation by DP83867 phy the INT/PWDN pin has to be
> programmed as an interrupt output instead of a Powerdown input in
> Configuration Register 3 (CFG3), Address 0x001E, bit 7 INT_OE = 1. The
> current driver doesn't do this and as result IRQs will not be generated by
> DP83867 phy even if they are properly configured in DT.
>
> Hence, fix IRQ generation by properly configuring CFG3.INT_OE bit and
> ensure that Link Status Change (LINK_STATUS_CHNG_INT) and Auto-Negotiation
> Complete (AUTONEG_COMP_INT) interrupt are enabled. After this the DP83867
> driver will work properly in interrupt enabled mode.
>
> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
> ---
> drivers/net/phy/dp83867.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
> index 1b63924..e84ae08 100644
> --- a/drivers/net/phy/dp83867.c
> +++ b/drivers/net/phy/dp83867.c
> @@ -29,6 +29,7 @@
> #define MII_DP83867_MICR 0x12
> #define MII_DP83867_ISR 0x13
> #define DP83867_CTRL 0x1f
> +#define DP83867_CFG3 0x1e
>
> /* Extended Registers */
> #define DP83867_RGMIICTL 0x0032
> @@ -98,6 +99,8 @@ static int dp83867_config_intr(struct phy_device *phydev)
> micr_status |=
> (MII_DP83867_MICR_AN_ERR_INT_EN |
> MII_DP83867_MICR_SPEED_CHNG_INT_EN |
> + MII_DP83867_MICR_AUTONEG_COMP_INT_EN |
> + MII_DP83867_MICR_LINK_STS_CHNG_INT_EN |
> MII_DP83867_MICR_DUP_MODE_CHNG_INT_EN |
> MII_DP83867_MICR_SLEEP_MODE_CHNG_INT_EN);
>
> @@ -214,6 +217,13 @@ static int dp83867_config_init(struct phy_device *phydev)
> }
> }
>
> + /* Enable Interrupt output INT_OE in CFG3 register */
> + if (phy_interrupt_is_valid(phydev)) {
> + val = phy_read(phydev, DP83867_CFG3);
> + val |= BIT(7);
> + phy_write(phydev, DP83867_CFG3, val);
> + }
Don't you need to clear that bit in the case phy_interrupt_is_valid()
returns false?
Other than that:
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
--
Florian
^ permalink raw reply
* [PATCH 6/6] arm64: dts: sunxi: add support for the Orange Pi PC 2 board
From: Maxime Ripard @ 2017-01-05 22:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161226171156.11605-3-icenowy@aosc.xyz>
On Tue, Dec 27, 2016 at 01:11:56AM +0800, Icenowy Zheng wrote:
> From: Andre Przywara <andre.przywara@arm.com>
>
> The Orange Pi PC 2 is a typical single board computer using the
> Allwinner H5 SoC. Apart from the usual suspects it features three
> separately driven USB ports and a Gigabit Ethernet port.
> Also it has a SPI NOR flash soldered, from which the board can boot
> from. This enables the SBC to behave like a "real computer" with
> built-in firmware.
>
> Add the board specific .dts file, which includes the H5 .dtsi and
> enables the peripherals that we support so far.
>
> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> ---
> arch/arm64/boot/dts/allwinner/Makefile | 1 +
> .../boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts | 183 +++++++++++++++++++++
> 2 files changed, 184 insertions(+)
> create mode 100644 arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts
>
> diff --git a/arch/arm64/boot/dts/allwinner/Makefile b/arch/arm64/boot/dts/allwinner/Makefile
> index 1e29a5ae8282..b26bb46b934c 100644
> --- a/arch/arm64/boot/dts/allwinner/Makefile
> +++ b/arch/arm64/boot/dts/allwinner/Makefile
> @@ -1,4 +1,5 @@
> dtb-$(CONFIG_ARCH_SUNXI) += sun50i-a64-pine64-plus.dtb sun50i-a64-pine64.dtb
> +dtb-$(CONFIG_ARCH_SUNXI) += sun50i-h5-orangepi-pc2.dtb
>
> always := $(dtb-y)
> subdir-y := $(dts-dirs)
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts
> new file mode 100644
> index 000000000000..a29ca6b274bb
> --- /dev/null
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-h5-orangepi-pc2.dts
> @@ -0,0 +1,183 @@
> +/*
> + * Copyright (C) 2016 ARM Ltd.
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + * a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file 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.
> + *
> + * Or, alternatively,
> + *
> + * b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +#include "sun50i-h5.dtsi"
> +
> +#include <dt-bindings/gpio/gpio.h>
> +#include <dt-bindings/input/input.h>
> +#include <dt-bindings/pinctrl/sun4i-a10.h>
> +
> +/ {
> + model = "Xunlong Orange Pi PC 2";
> + compatible = "xunlong,orangepi-pc2", "allwinner,sun50i-h5";
> +
> + reg_vcc3v3: vcc3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc3v3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + };
> +
> + aliases {
> + serial0 = &uart0;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + pinctrl-names = "default";
> + pinctrl-0 = <&leds_opc>, <&leds_r_opc>;
There's no need to declare the LED GPIO in pinctrl.
> +
> + pwr_led {
> + label = "orangepi:green:pwr";
> + gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>;
> + default-state = "on";
> + };
> +
> + status_led {
> + label = "orangepi:red:status";
> + gpios = <&pio 0 15 GPIO_ACTIVE_HIGH>;
> + };
> + };
> +
> + r_gpio_keys {
> + compatible = "gpio-keys";
> + pinctrl-names = "default";
> + pinctrl-0 = <&sw_r_opc>;
Ditto
> +
> + sw4 {
> + label = "sw4";
> + linux,code = <BTN_0>;
> + gpios = <&r_pio 0 3 GPIO_ACTIVE_LOW>;
> + };
> + };
> +};
> +
> +&ehci1 {
> + status = "okay";
> +};
> +
> +&ehci2 {
> + status = "okay";
> +};
> +
> +&ehci3 {
> + status = "okay";
> +};
> +
> +&ir {
> + pinctrl-names = "default";
> + pinctrl-0 = <&ir_pins_a>;
> + status = "okay";
> +};
> +
> +&mmc0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
Ditto
> + vmmc-supply = <®_vcc3v3>;
> + bus-width = <4>;
> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
> + cd-inverted;
Do you need both the GPIO flag and the cd-inverted one?
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/20170105/59c73b72/attachment.sig>
^ permalink raw reply
* [arm:clearfog 25/65] htmldocs: drivers/net/phy/phy.c:278: warning: No description found for parameter 'speed'
From: kbuild test robot @ 2017-01-05 22:19 UTC (permalink / raw)
To: linux-arm-kernel
tree: git://git.armlinux.org.uk/~rmk/linux-arm.git clearfog
head: a0b3b7ea35687eaa7b1836bcdbbe10daf034c621
commit: b73483caa6bece0e854d064bb931dc25f84c935e [25/65] net: phy: improve phylib correctness for non-autoneg settings
reproduce: make htmldocs
All warnings (new ones prefixed by >>):
>> drivers/net/phy/phy.c:278: warning: No description found for parameter 'speed'
>> drivers/net/phy/phy.c:278: warning: No description found for parameter 'duplex'
>> drivers/net/phy/phy.c:278: warning: No description found for parameter 'supported'
>> drivers/net/phy/phy.c:278: warning: No description found for parameter 'speed'
>> drivers/net/phy/phy.c:278: warning: No description found for parameter 'duplex'
>> drivers/net/phy/phy.c:278: warning: No description found for parameter 'supported'
vim +/speed +278 drivers/net/phy/phy.c
b73483ca Russell King 2017-01-05 262 break;
b73483ca Russell King 2017-01-05 263 }
b73483ca Russell King 2017-01-05 264 }
b73483ca Russell King 2017-01-05 265 }
00db8189 Andy Fleming 2005-07-30 266
b73483ca Russell King 2017-01-05 267 if (!match && !exact)
b73483ca Russell King 2017-01-05 268 match = last;
00db8189 Andy Fleming 2005-07-30 269
b73483ca Russell King 2017-01-05 270 return match;
00db8189 Andy Fleming 2005-07-30 271 }
00db8189 Andy Fleming 2005-07-30 272
b3df0da8 Randy Dunlap 2007-03-06 273 /**
b3df0da8 Randy Dunlap 2007-03-06 274 * phy_find_valid - find a PHY setting that matches the requested features mask
00db8189 Andy Fleming 2005-07-30 275 */
b73483ca Russell King 2017-01-05 276 static const struct phy_setting *
b73483ca Russell King 2017-01-05 277 phy_find_valid(int speed, int duplex, u32 supported)
00db8189 Andy Fleming 2005-07-30 @278 {
b73483ca Russell King 2017-01-05 279 unsigned long mask = supported;
00db8189 Andy Fleming 2005-07-30 280
b73483ca Russell King 2017-01-05 281 return phy_lookup_setting(speed, duplex, &mask, BITS_PER_LONG, false);
00db8189 Andy Fleming 2005-07-30 282 }
00db8189 Andy Fleming 2005-07-30 283
b3df0da8 Randy Dunlap 2007-03-06 284 /**
54da5a8b Guenter Roeck 2015-02-17 285 * phy_check_valid - check if there is a valid PHY setting which matches
54da5a8b Guenter Roeck 2015-02-17 286 * speed, duplex, and feature mask
:::::: The code at line 278 was first introduced by commit
:::::: 00db8189d984d6c51226dafbbe4a667ce9b7d5da This patch adds a PHY Abstraction Layer to the Linux Kernel, enabling ethernet drivers to remain as ignorant as is reasonable of the connected PHY's design and operation details.
:::::: TO: Andy Fleming <afleming@freescale.com>
:::::: CC: Jeff Garzik <jgarzik@pobox.com>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: .config.gz
Type: application/gzip
Size: 6421 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20170106/f92d6b9a/attachment-0001.gz>
^ permalink raw reply
* [PATCH v2 05/19] ARM: dts: imx6-sabresd: add OV5642 and OV5640 camera sensors
From: Steve Longerbeam @ 2017-01-05 22:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c8c09060-dd6b-f495-da7d-b1f9fad79b89@mentor.com>
On 01/04/2017 04:33 AM, Vladimir Zapolskiy wrote:
>
>> +
>> + camera: ov5642 at 3c {
> ov5642: camera at 3c
done.
>> + pwdn-gpios = <&gpio1 16 GPIO_ACTIVE_HIGH>; /* SD1_DAT0 */
>> + reset-gpios = <&gpio1 17 GPIO_ACTIVE_LOW>; /* SD1_DAT1 */
> Comments about SD1_* pad names are redundant.
sure, removed.
>> + status = "disabled";
> Why is it disabled here?
It's explained in the header. I don't yet have the OV5642 module for
the sabresd for testing, so it is disabled for now.
>> +
>> + mipi_camera: ov5640 at 3c {
> ov5640: camera at 3c
done.
>
>> + pwdn-gpios = <&gpio1 19 GPIO_ACTIVE_HIGH>; /* SD1_DAT2 */
>> + reset-gpios = <&gpio1 20 GPIO_ACTIVE_LOW>; /* SD1_CLK */
> Comments about SD1_* pad names are redundant.
removed.
>> +
>> + pinctrl_ipu1_csi0: ipu1grp-csi0 {
> Please rename the node name to ipu1csi0grp.
>
> Please add new pin control groups preserving the alphanimerical order.
done and done.
Steve
^ permalink raw reply
* [PATCH V6 05/10] acpi: apei: handle SEA notification type for ARMv8
From: Baicar, Tyler @ 2017-01-05 22:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <58594E62.3050003@arm.com>
On 12/20/2016 8:29 AM, James Morse wrote:
> Hi Tyler,
>
> On 07/12/16 21:48, Tyler Baicar wrote:
>> ARM APEI extension proposal added SEA (Synchrounous External
>> Abort) notification type for ARMv8.
>> Add a new GHES error source handling function for SEA. If an error
>> source's notification type is SEA, then this function can be registered
>> into the SEA exception handler. That way GHES will parse and report
>> SEA exceptions when they occur.
>> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
>> index 2acbc60..66ab3fd 100644
>> --- a/drivers/acpi/apei/ghes.c
>> +++ b/drivers/acpi/apei/ghes.c
>> @@ -767,6 +771,62 @@ static struct notifier_block ghes_notifier_sci = {
>> .notifier_call = ghes_notify_sci,
>> };
>>
>> +#ifdef CONFIG_HAVE_ACPI_APEI_SEA
>> +static LIST_HEAD(ghes_sea);
>> +
>> +static int ghes_notify_sea(struct notifier_block *this,
>> + unsigned long event, void *data)
>> +{
>> + struct ghes *ghes;
>> + int ret = NOTIFY_DONE;
>> +
>> + rcu_read_lock();
>> + list_for_each_entry_rcu(ghes, &ghes_sea, list) {
>> + if (!ghes_proc(ghes))
>> + ret = NOTIFY_OK;
>> + }
>> + rcu_read_unlock();
>> +
>> + return ret;
>> +}
> What stops this from being re-entrant?
>
> ghes_copy_tofrom_phs() takes the ghes_ioremap_lock_irq spinlock, but there is
> nothing to stop a subsequent instruction fetch or memory access causing another
> (maybe different) Synchronous External Abort which deadlocks trying to take the
> same lock.
>
> ghes_notify_sea() looks to be based on ghes_notify_sci(), which (if I've found
> the right part of the ACPI spec) is a level-low interrupt. spin_lock_irqsave()
> would mask interrupts so there is no risk of a different notification firing on
> the same CPU, (it looks like they are almost all ultimately an irq).
>
> NMI is the odd one out because its not maskable like this, but ghes_notify_nmi()
> has:
>> if (!atomic_add_unless(&ghes_in_nmi, 1, 1))
>> return ret;
> To ensure there is only ever one thread poking around in this code.
>
> What happens if a system describes two GHES sources, one using an irq the other
> SEA? The SEA error can interrupt the irq error while its holding the above lock.
> I guess this is also why all the NMI code in that file is separate.
>
>
> Thanks,
>
> James
Hi James,
Let me see if I'm following you right :)
I should use spin_lock_irqsave() in ghes_notify_sea() to avoid
ghes_notify_sci() from
interrupting this process and potentially causing the deadlock?
This race condition does seem valid. We are using the same
acknowledgment for all our
HEST table entries, so our firmware will not populate more than one
entry at a time. That
gets us around this race condition.
Thanks,
Tyler
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v2 09/19] ARM: dts: imx6-sabreauto: add the ADV7180 video decoder
From: Steve Longerbeam @ 2017-01-05 22:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <acbdc873-3166-f56d-e6d1-948becb1a57c@mentor.com>
On 01/04/2017 04:41 AM, Vladimir Zapolskiy wrote:
> On 01/03/2017 10:57 PM, Steve Longerbeam wrote:
>> +
>> + camera: adv7180 at 21 {
> adv7180: camera at 21
done.
>>
>> + pinctrl_ipu1_csi0: ipu1grp-csi0 {
> Please rename node name to ipu1csi0grp.
done.
Steve
^ permalink raw reply
* [linux-sunxi] [PATCH 1/2] drivers: pinctrl: add driver for Allwinner H5 SoC
From: Maxime Ripard @ 2017-01-05 22:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYQhfid3VRcaj=7as_+Zg=pX3Svp9FJ_W_Ft8nVuoZqKQ@mail.gmail.com>
On Fri, Dec 30, 2016 at 01:55:44PM +0100, Linus Walleij wrote:
> On Mon, Dec 26, 2016 at 3:33 PM, Andr? Przywara <andre.przywara@arm.com> wrote:
>
> > So while this patch technically looks correct, I was wondering if we
> > should really explore the possibility of making the whole of sunxi
> > pinctrl DT controlled.
> > I brought this up a while ago, but people weren't overly enthusiastic
> > about it, though their argument weren't really convincing to me[1].
> >
> > So:
> > As this "driver" here is basically a table linking GPIO bit settings
> > (the actual mux value) to names and every pin we care about needs to be
> > enumerated in the DT anyway, why not just add something like:
> > allwinner,pinmux = <4>;
> > to each pin(group) in the DT and get rid of this "driver" file here
> > entirely?
>
> I'm open to that if you can use pinctrl-single which is in the kernel
> for this purpose only, and is used with both OMAPs and HiSilicon.
I'm not open to that, and I'm getting tired of discussing it over and
over again. Andre, if you want to be convinced again, please read the
last discussion we had on this topic.
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/20170105/98ba8d71/attachment.sig>
^ permalink raw reply
* next-20170105 build: 4 failures 3 warnings (next-20170105)
From: Stephen Rothwell @ 2017-01-05 22:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170105195546.wnmjwh4hazqiyodf@sirena.org.uk>
Hi Mark,
On Thu, 5 Jan 2017 19:55:46 +0000 Mark Brown <broonie@kernel.org> wrote:
>
> On Thu, Jan 05, 2017 at 12:07:08PM +0000, Build bot for Mark Brown wrote:
>
> Since sometime over the Christmas vacation all arm64 configs have been
> failing to build due to:
>
> > ../arch/arm64/include/asm/setup.h:14:29: error: redefinition of 'kaslr_offset'
>
> (same error repeating a different number of times for each config).
> This is an interaction between Andrew's -current tree and Linus' tree.
> Andrew's tree has "arm64: setup: introduce kaslr_offset()"
> (1a339a14b1f2c7 in current -next) and Linus' tree has a commit
> 7ede8665f27cde7d with the same title but a modified version that went to
> Linus through Will. In the version in Andrew's tree kaslr_offset() is
> defined in asm/setup.h while in the version in Linus' tree it is
> instead defined in asm/memory.h so -next ends up with two definitions of
> that function causing the build errors.
>
> I guess the commit in Andrew's tree should be dropped now, reverting it
> fixes the builds for me.
OK, I have now dropped the initial part of akpm's -current tree that
was sent to Linus (including the above commit). Sorry for not noticing
earlier.
Andrew, this means that your tree in linux-next now contains:
a63a9bb7abd2 ipc/sem: add hysteresis
07be42f325e3 ipc/sem.c: avoid using spin_unlock_wait()
6d3a63124caa scripts/gdb: add lx-fdtdump command
138d8657d5ff kdump, vmcoreinfo: report actual value of phys_base
67dbc87b155b lib: Add CRC64 ECMA module
30daa67dc769 mm/vmstat.c: walk the zone in pageblock_nr_pages steps
d5419fdf6ed6 mm/page_owner: align with pageblock_nr pages
6eb902b75775 z3fold: fix locking issues
2fb167a08fa3 z3fold: fix header size related issues
c7f6417f13f6 z3fold: discourage use of pages that weren't compacted
8e40c9ecad02 z3fold: use per-page spinlock
9d759ab4feec mm/z3fold.c: extend compaction function
e22149b524d9 mm/z3fold.c: make pages_nr atomic
cb9a2fb0a835 mm/z3fold.c: limit first_num to the actual range of possible buddy indexes
1411714ceeee mm, page_alloc: avoid page_to_pfn() when merging buddies
794cc4aa50dc mm, page_alloc: don't convert pfn to idx when merging
8c0ff3c42376 mm-throttle-show_mem-from-warn_alloc-fix
e4974bce6cc7 mm: throttle show_mem() from warn_alloc()
4b2de28ffcd0 tmpfs: change shmem_mapping() to test shmem_aops
1143ed06c725 kernel-watchdog-prevent-false-hardlockup-on-overloaded-system-fix
6904a50482ee kernel/watchdog: prevent false hardlockup on overloaded system
04a26c045475 block: restore /proc/partitions to not display non-partitionable removable devices
409d7387f7be ocfs2: fix crash caused by stale lvb with fsdlm plugin
27040ecd9fbb ocfs2-old-mle-put-and-release-after-the-function-dlm_add_migration_mle-called-fix
c19202b8a963 ocfs2: old mle put and release after the function dlm_add_migration_mle called
d82c60f3a069 scripts/spelling.txt: add several more common spelling mistakes
af85e2db2cba arm: arch/arm/include/asm/page.h needs personality.h
3da3cb66bb1b mm/thp/pagecache/collapse: free the pte page table on collapse for thp page cache.
3180061bc2fd mm/thp/pagecache: only withdraw page table after a successful deposit
(merge linux-next - akpm stuff)
4453f4fde106 scripts/spelling.txt: add "followings" pattern and fix typo instances
f1c251fd2f4a scripts/spelling.txt: add "therfore" pattern and fix typo instances
09029516eb46 scripts/spelling.txt: add "overwriten" pattern and fix typo instances
a1d75390cb06 scripts/spelling.txt: add "overwritting" pattern and fix typo instances
174def646afe scripts/spelling.txt: add "deintialize(d)" pattern and fix typo instances
a3475e364975 scripts/spelling.txt: add "disassocation" pattern and fix typo instances
f8fa89870426 scripts/spelling.txt: add "omited" pattern and fix typo instances
a907cffe94c0 scripts/spelling.txt: add "explictely" pattern and fix typo instances
382a878623a8 scripts/spelling.txt: add "applys" pattern and fix typo instances
b349d54c456a scripts/spelling.txt: add "configuartion" pattern and fix typo instances
38bfb6e670f4 scripts/spelling.txt: add "overrided" pattern and fix typo instances
5453cfe4dc41 scripts/spelling.txt: add "overide" pattern and fix typo instances
4ad56706176e scripts/spelling.txt: add "disble(d)" pattern and fix typo instances
342f1c20e5c5 scripts/spelling.txt: add "comsume(r)" pattern and fix typo instances
4787ac5086e0 scripts/spelling.txt: add "intialise(d)" pattern and fix typo instances
46283934f6ae scripts/spelling.txt: add "initialiazation" pattern and fix typo instances
df8e7e0a5bc4 scripts/spelling.txt: add "intialization" pattern and fix typo instances
2f336b08f6f0 scripts/spelling.txt: add "unneded" pattern and fix typo instances
33faac7f1266 scripts/spelling.txt: add "neded" pattern and fix typo instances
c0c9925ac473 scripts/spelling.txt: add "againt" pattern and fix typo instances
f6efcac2efe0 scripts/spelling.txt: add "embeded" pattern and fix typo instances
7590c4f7f34b scripts/spelling.txt: add "varible" pattern and fix typo instances
36b857060ad7 scripts/spelling.txt: add "efective" pattern and fix typo instances
268f025aa99f scripts/spelling.txt: add "algined" pattern and fix typo instances
9fc9398d752e scripts/spelling.txt: add "aligment" pattern and fix typo instances
7b2467807cbc scripts/spelling.txt: add "partiton" pattern and fix typo instances
fea25f1f9e37 scripts/spelling.txt: add "an one" pattern and fix typo instances
84860c6996c9 scripts/spelling.txt: add "an union" pattern and fix typo instances
a9a1e595ac30 scripts/spelling.txt: add "an user" pattern and fix typo instances
4bde980b9c4a scripts/spelling.txt: add "swithc" pattern and fix typo instances
f19ed214ee17 scripts/spelling.txt: add "swith" pattern and fix typo instances
0f401b986050 reimplement-idr-and-ida-using-the-radix-tree-support-storing-null-in-the-idr-checkpatch-fixes
6bfd1dd54e38 idr: support storing NULL in the IDR
9b54b6ba4a61 Reimplement IDR and IDA using the radix tree
6dde86413add fs: add i_blocksize()
--
Cheers,
Stephen Rothwell
^ 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