[PATCH v2] ARC: Configure APB GPIO controller on ARC HSDK platform
In case of HSDK we have intermediate INTC in for of DW APB GPIO controller
which is used as a de-bounce logic for interrupt wires that come from
outside the board.
We cannot use existing "irq-dw-apb-ictl" driver here because all input
lines are routed to corresponding output lines but not muxed into one
line (this is configured in RTL and we cannot change this in software).
But even if we add such a feature to "irq-dw-apb-ictl" driver that won't
benefit us as higher-level INTC (in case of HSDK it is IDU) anyways has
per-input control so adding fully-controller intermediate INTC will only
bring some overhead on interrupt processing but no other benefits.
Thus we just do one-time configuration of DW APB GPIO controller and
forget about it.
Based on implementation available on arch/arc/plat-axs10x/axs10x.c file.
Signed-off-by: Gustavo Pimentel
---
arch/arc/plat-hsdk/platform.c | 62 +++
1 file changed, 62 insertions(+)
diff --git a/arch/arc/plat-hsdk/platform.c b/arch/arc/plat-hsdk/platform.c
index 2958aed..2588b84 100644
--- a/arch/arc/plat-hsdk/platform.c
+++ b/arch/arc/plat-hsdk/platform.c
@@ -42,6 +42,66 @@ static void __init hsdk_init_per_cpu(unsigned int cpu)
#define SDIO_UHS_REG_EXT (SDIO_BASE + 0x108)
#define SDIO_UHS_REG_EXT_DIV_2 (2 << 30)
+#define HSDK_GPIO_INTC (ARC_PERIPHERAL_BASE + 0x3000)
+
+static void __init hsdk_enable_gpio_intc_wire(void)
+{
+ /*
+* Peripherals on CPU Card are wired to cpu intc via intermediate
+* DW APB GPIO blocks (mainly for debouncing)
+*
+* -
+*| snps,archs-intc |
+*-
+* |
+*--
+*| snps,archs-idu-intc |
+*--
+* | | | ||
+* | [eth] [USB][... other peripherals]
+* |
+* ---
+* | snps,dw-apb-intc |
+* ---
+* | | | |
+* [Bt] [HAPS] [... other peripherals]
+*
+* Current implementation of "irq-dw-apb-ictl" driver doesn't work well
+* with stacked INTCs. In particular problem happens if its master INTC
+* not yet instantiated. See discussion here -
+* https://lkml.org/lkml/2015/3/4/755
+*
+* So setup the first gpio block as a passive pass thru and hide it from
+* DT hardware topology - connect intc directly to cpu intc
+* The GPIO "wire" needs to be init nevertheless (here)
+*
+* One side adv is that peripheral interrupt handling avoids one nested
+* intc ISR hop
+*
+* According to HSDK User's Manual [1], "Table 2 Interrupt Mapping"
+* we have the following GPIO input lines used as sources of interrupt:
+* - GPIO[0] - Bluetooth interrupt of RS9113 module
+* - GPIO[2] - HAPS interrupt (on HapsTrak 3 connector)
+* - GPIO[3] - Audio codec (MAX9880A) interrupt
+* - GPIO[8-23] - Available on Arduino and PMOD_x headers
+* For now there's no use of Arduino and PMOD_x headers in Linux
+* use-case so we only enable lines 0, 2 and 3.
+*
+* [1]
https://github.com/foss-for-synopsys-dwc-arc-processors/ARC-Development-Systems-Forum/wiki/docs/ARC_HSDK_User_Guide.pdf
+*/
+#define GPIO_INTEN (HSDK_GPIO_INTC + 0x30)
+#define GPIO_INTMASK(HSDK_GPIO_INTC + 0x34)
+#define GPIO_INTTYPE_LEVEL (HSDK_GPIO_INTC + 0x38)
+#define GPIO_INT_POLARITY (HSDK_GPIO_INTC + 0x3c)
+#define GPIO_INT_CONNECTED_MASK0x0d
+
+ iowrite32(0x, (void __iomem *) GPIO_INTMASK);
+ iowrite32(~GPIO_INT_CONNECTED_MASK, (void __iomem *) GPIO_INTMASK);
+ iowrite32(0x, (void __iomem *) GPIO_INTTYPE_LEVEL);
+ iowrite32(0x, (void __iomem *) GPIO_INT_POLARITY);
+ iowrite32(GPIO_INT_CONNECTED_MASK, (void __iomem *) GPIO_INTEN);
+}
+
static void __init hsdk_init_early(void)
{
/*
@@ -62,6 +122,8 @@ static void __init hsdk_init_early(void)
* minimum possible div-by-2.
*/
iowrite32(SDIO_UHS_REG_EXT_DIV_2, (void __iomem *) SDIO_UHS_REG_EXT);
+
+ hsdk_enable_gpio_intc_wire();
}
static const char *hsdk_compat[] __initconst = {
--
2.7.4
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] ARC: prevent showing irrelevant exception info in signal message
Hi Vineet, On Thu, 2018-07-05 at 14:26 -0700, Vineet Gupta wrote: > On 07/03/2018 03:57 AM, Eugeniy Paltsev wrote: > > On Mon, 2018-07-02 at 10:57 -0700, Vineet Gupta wrote: > > > +CC Al > > > > > > On 06/29/2018 12:39 PM, Eugeniy Paltsev wrote: > > > > We process signals in the end of syscall/exception handler. > > > > It the signal is fatal we print register's content using > > > > show_regs function. show_regs() also prints information about > > > > last exception happened. > > > > > > > > In case of multicore system we can catch the situation when we > > > > will print wrong information about exception. See the example: > > > > __ > > > > CPU-0: started to handle page fault > > > > CPU-1: sent signal to process, which is executed on CPU-0 > > > > CPU-0: ended page fault handle. Started to process signal before > > > >returnig to userspace. Process signal, which is send from > > > >CPU-0. As th signal is fatal we call show_regs(). > > > >show_regs() will show information about last exception > > > >which is *page fault* (instead of "trap" which is used for > > > >signals and happened on CPU-0) > > > > > > > > So we will get message like this: > > > > /home/waitpid02 > > > > potentially unexpected fatal signal 8. > > > > Path: /home/waitpid02 > > > > CPU: 0 PID: 100 Comm: waitpid02 Not tainted 4.10.0-rc4 #2 > > > > task: 9f11c200 task.stack: 9f3ae000 > > > > > > > > [ECR ]: 0x00050200 => Invalid Write @ 0x by insn @ > > > > 0x000123ec > > > > [EFA ]: 0x > > > > [BLINK ]: 0x123ea > > > > [ERET ]: 0x123ec > > > > @off 0x123ec in [/home/waitpid02] > > > > VMA: 0x0001 to 0x00016000 > > > > [STAT32]: 0x80080882 : IE U > > > > BTA: 0x000123ea SP: 0x5ffd3db0 FP: 0x > > > > LPS: 0x20031684 LPE: 0x2003169a LPC: 0x0006 > > > > [-other-info-] > > > > > > > > This message is confusing because it show information about page fault > > > > ( [ECR ]: 0x00050200 => Invalid Write ) which is absolutely irrelevant > > > > to signal. > > > > > > Agreed this is misleading. @Al, is there a way to identify process > > > termination > > > from signals because it did something wrong vs. say unhandled signal. For > > > former, > > > we want to dump additional info in show_regs() such as PC / Fault addres > > > etc and > > > not in other scenario. > > > > > > > This situation was reproduced with waitpid02 LTP test. > > > > _ > > > > > > > > So remove printing information about exceptions from show_regs() > > > > to avoid confusing messages. Print information about exceptions > > > > only in required places instead of show_regs() > > > > > > > > Now we don't print information about exceptions if signal is simply > > > > send by another userspace app. So in case of waitpid02 we will print > > > > next message: > > > > _ > > > > ./waitpid02 > > > > potentially unexpected fatal signal 8. > > > > [STAT32]: 0x80080082 : IE U > > > > BTA: 0x2fc4SP: 0x5ff8bd64 FP: 0x > > > > LPS: 0x200524a0 LPE: 0x200524b6 LPC: 0x0006 > > > > [-other-info-] > > > > _ > > > > > > The prints I'm seeing now, for a segv from NULL pointer access is even > > > more > > > confusing ! > > > There's a mixup of prints > > > > > > >8 > > > Path: /segv > > > CPU: 0 PID: 70 Comm: segv Not tainted 4.17.0+ #412 > > > > > > [ECR ]: 0x00050200 => Invalid Write @ 0x by insn @ 0x000103ac > > > [EFA ]: 0x > > > [BLINK ]: 0x20047bb0 > > > [ERET ]: 0x103ac > > > @off 0x103ac in [/segv] > > > VMA: 0x0001 to 0x00012000 > > > > > > potentially unexpected fatal signal 11. > > > [STAT32]: 0x80080882 : IE U > > > BTA: 0x00010398 SP: 0x5fc95e1c FP: 0x5fc95e20 > > > LPS: 0x20039ffcLPE: 0x2003a000LPC: 0x > > > r00: 0x0001r01: 0x5fc95e94r02: 0x > > > r03: 0x0064r04: 0x80808080r05: 0x2f2f2f2f > > > ... > > > >8 > > > > > > and for the process killed by signal 8, we get below. > > > > > > >8 > > > [ARCLinux]# kill -8 71 > > > [ARCLinux]# potentially unexpected fatal signal 8. > > > [STAT32]: 0x80080882 : IE U > > > BTA: 0x20020660 SP: 0x5fbcddec FP: 0x5fbcde1c > > > LPS: 0x20039ffcLPE: 0x2003a000LPC: 0x > > > r00: 0xfdfcr01: 0x5fbcddf0r02: 0x > > > r03: 0x0008r04: 0x80808080r05: 0x2f2f2f2f > > > r06: 0x7a2f5f4ar07: 0xr08: 0x0065 > > > ... > > > > > > > > > [1]+ Floating point exception ./sleep > > > >8 > > > I'm not sure whats the improvement here vs. the status quo. > > > > Why do you think this is confusing? > > The main change is
Re: [PATCH] ARC: Remove CONFIG_INITRAMFS_SOURCE from defconfigs
Hi Vineet, On Wed, 2018-06-06 at 09:32 -0700, Kevin Hilman wrote: > On Wed, Jun 6, 2018 at 5:59 AM, Alexey Brodkin > wrote: > > We used to have pre-set CONFIG_INITRAMFS_SOURCE with local path > > to intramfs in ARC defconfigs. This was quite convenient for > > in-house development but not that convenient for newcomers > > who obviusly don't have folders like "arc_initramfs" next to > > the Linux source tree. Which leads to quite surprising failure > > of defconfig building: > > --->8- > > ../scripts/gen_initramfs_list.sh: Cannot open '../../arc_initramfs_hs/' > > ../usr/Makefile:57: recipe for target 'usr/initramfs_data.cpio.gz' failed > > make[2]: *** [usr/initramfs_data.cpio.gz] Error 1 > > --->8- > > > > So now when more and more people start to deal with our defconfigs > > let's make their life easier with removal of CONFIG_INITRAMFS_SOURCE. > > > > Signed-off-by: Alexey Brodkin > > Cc: Kevin Hilman > > Cc: sta...@vger.kernel.org > > > > Signed-off-by: Alexey Brodkin > > Reviewed-by: Kevin Hilman > Tested-by: Kevin Hilman Any chance for this one to hit upstream sometime soon? -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v2] ARC: Configure APB GPIO controller on ARC HSDK platform
Hi Gustavo, On Fri, 2018-07-06 at 11:32 +0100, Gustavo Pimentel wrote: > In case of HSDK we have intermediate INTC in for of DW APB GPIO controller > which is used as a de-bounce logic for interrupt wires that come from > outside the board. > > We cannot use existing "irq-dw-apb-ictl" driver here because all input > lines are routed to corresponding output lines but not muxed into one > line (this is configured in RTL and we cannot change this in software). > > But even if we add such a feature to "irq-dw-apb-ictl" driver that won't > benefit us as higher-level INTC (in case of HSDK it is IDU) anyways has > per-input control so adding fully-controller intermediate INTC will only > bring some overhead on interrupt processing but no other benefits. > > Thus we just do one-time configuration of DW APB GPIO controller and > forget about it. > > Based on implementation available on arch/arc/plat-axs10x/axs10x.c file. > > Signed-off-by: Gustavo Pimentel Acked-by: Alexey Brodkin ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] devres: Really align data field to unsigned long long
It looks like on most of architectures "data" member of devres struture
gets aligned to 8-byte "unsigned long long" boundary as one may expect:
if we don't explicitly pack a structure then natural alignment
(which matches each member data type) is used.
But at least on 32-bit ARC architecture ABI requires "long long" types
to be aligned by normal 32-bit word. This makes "data" field aligned to
12 bytes. This is still OK as long as we use 32-bit data only.
But once we want to use native atomic64_t type (i.e. when we use special
instructions LLOCKD/SCONDD for accessing 64-bit data) we easily hit
misaligned access exception.
That's because even on CPUs capable of non-aligned data access LL/SC
instructions require strict alignment.
Signed-off-by: Alexey Brodkin
Cc: sta...@vger.kernel.org
---
drivers/base/devres.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/base/devres.c b/drivers/base/devres.c
index f98a097e73f2..35ddc8b66bc9 100644
--- a/drivers/base/devres.c
+++ b/drivers/base/devres.c
@@ -25,7 +25,7 @@ struct devres_node {
struct devres {
struct devres_node node;
/* -- 3 pointers */
- unsigned long long data[]; /* guarantee ull alignment */
+ unsigned long long data[] __aligned(sizeof(unsigned long
long));
};
struct devres_group {
--
2.17.1
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] devres: Really align data field to unsigned long long
On Fri, 6 Jul 2018, Alexey Brodkin wrote:
> It looks like on most of architectures "data" member of devres struture
> gets aligned to 8-byte "unsigned long long" boundary as one may expect:
> if we don't explicitly pack a structure then natural alignment
> (which matches each member data type) is used.
>
> But at least on 32-bit ARC architecture ABI requires "long long" types
> to be aligned by normal 32-bit word. This makes "data" field aligned to
> 12 bytes. This is still OK as long as we use 32-bit data only.
>
> But once we want to use native atomic64_t type (i.e. when we use special
> instructions LLOCKD/SCONDD for accessing 64-bit data) we easily hit
> misaligned access exception.
>
> That's because even on CPUs capable of non-aligned data access LL/SC
> instructions require strict alignment.
>
> Signed-off-by: Alexey Brodkin
> Cc: sta...@vger.kernel.org
> ---
> drivers/base/devres.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/base/devres.c b/drivers/base/devres.c
> index f98a097e73f2..35ddc8b66bc9 100644
> --- a/drivers/base/devres.c
> +++ b/drivers/base/devres.c
> @@ -25,7 +25,7 @@ struct devres_node {
> struct devres {
> struct devres_node node;
> /* -- 3 pointers */
> - unsigned long long data[]; /* guarantee ull alignment */
Pretty please put a big fat comment here so that the innocent reader does
not start to wonder.
> + unsigned long long data[] __aligned(sizeof(unsigned long
> long));
> };
Thanks,
tglx
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
