Re: [PATCH v3 2/2] DW DMAC: add multi-block property to device tree

2016-11-22 Thread Vinod Koul 
On Fri, Nov 18, 2016 at 09:33:13PM +0200, Andy Shevchenko wrote:
> > @@ -1569,7 +1569,7 @@ int dw_dma_probe(struct dw_dma_chip *chip)
> >     (dwc_params >> DWC_PARAMS_MBLK_EN &
> > 0x1) == 0;
> >     } else {
> >     dwc->block_size = pdata->block_size;
> > -   dwc->nollp = pdata->is_nollp;
> > +   dwc->nollp = pdata->multi_block[i];
> 
> You missed the point. You assign positive value to negative variable.
> It's a bug. Have you tested this? How?
> 
> In case of positive property you have to update DTS. By the way, I'm
> pretty sure that spare13xx boards has auto configuration enabled, though
> it has to be checked with vendor (I assume you may have fast response
> from them).

Yeah why are we not using auto configuration here would be the first
question..

-- 
~Vinod

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH v3 0/2] DW DMAC: update device tree

2016-11-22 Thread Vinod Koul 
On Mon, Nov 21, 2016 at 12:37:06PM +0200, Andy Shevchenko wrote:
> On Mon, 2016-11-21 at 10:02 +, Alexey Brodkin wrote:
> > Hi Andy,
> > 
> > On Fri, 2016-11-18 at 21:26 +0200, Andy Shevchenko wrote:
> > > On Fri, 2016-11-18 at 22:12 +0300, Eugeniy Paltsev wrote:
> > > > 
> > > > It wasn't possible to enable some features like
> > > > memory-to-memory transfers or multi block transfers via DT.
> > > > It is fixed by these patches.
> > > 
> > > First of all, please, give time to reviewers to comment the patches.
> > > Usually it should be at least 24h (for the series that has been sent
> > > first time 1 week approximately).
> > 
> > I'm not really sure a lot of people get disturbed by this series
> > and given this all has been discussed for months now I'd really like
> > to see changes required for our HW to work to land in upstream ASAP.
> 
> I understand your concern, I'm often in the same position in many areas,
> including this driver (I'm not a maintainer of slave DMA subsystem).
> 
> Though let's face the issues we have with the series:
> - stuff regarding to style and alike (would be fixed in a day)
> - DTS naming and conventions, this is apparently a big area, where I
> might share opinion, but can't decide for
> - last word by the subsystem maintainer
> 
> > Too bad we're late for 4.9 (which is supposed to be the next LTS) but
> > > we need to make sure this series hits 4.10 for sure.
> 
> Vinod, is it possible to get in for this series (if we get Ack from DT
> people)?

We still have a week or so... But holding race agaisnt upstream is a bad
idea... Doesnt work that way.

-- 
~Vinod

___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

[PATCH 3/6] arc: Use full path in KBUILD_IMAGE definition

2016-11-22 Thread Michal Marek 
The KBUILD_IMAGE variable is used by the rpm and deb-pkg targets, which
expect it to point to the image file in the build directory. The
builddeb script has a workaround for architectures which only provide
the basename, but let's provide a clean interface for packaging tools.

Cc: Vineet Gupta 
Cc: linux-snps-arc@lists.infradead.org
Signed-off-by: Michal Marek 
---
 arch/arc/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arc/Makefile b/arch/arc/Makefile
index 19cce226d1a8..44ef35d33956 100644
--- a/arch/arc/Makefile
+++ b/arch/arc/Makefile
@@ -123,9 +123,9 @@ libs-y  += arch/arc/lib/ $(LIBGCC)
 boot   := arch/arc/boot
 
 #default target for make without any arguments.
-KBUILD_IMAGE   := bootpImage
+KBUILD_IMAGE   := $(boot)/bootpImage
 
-all:   $(KBUILD_IMAGE)
+all:   bootpImage
 bootpImage: vmlinux
 
 boot_targets += uImage uImage.bin uImage.gz
-- 
2.10.0


___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

[PATCH] ARC: axs10x: really enable ARC PGU

2016-11-22 Thread Alexey Brodkin 
Up until now we had ARC PGU not enabled in axs10x defconfigs trying
to not bloat kernel image again with yet another drivers and subsystems.

This change configures ARC PGU (as well as DRM bits it depends on)
to be built as a module and so those who need LCD screen to work on
axs10x may bundle built .ko files in their target's file-system with
help of the following command on host:
->8-
make INSTALL_MOD_PATH=_path_to_target_fs_ modules_install
->8-

and later on target with commands as simple as:
->8-
modprobe adv7511.ko
modprobe arcpgu.ko
->8-
get LCD working.

Signed-off-by: Alexey Brodkin 
---
 arch/arc/boot/dts/axs101.dts  | 2 +-
 arch/arc/boot/dts/axs103_idu.dts  | 2 +-
 arch/arc/configs/axs101_defconfig | 4 +++-
 arch/arc/configs/axs103_smp_defconfig | 4 +++-
 4 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/arch/arc/boot/dts/axs101.dts b/arch/arc/boot/dts/axs101.dts
index d9b9b9dcfc4c..70aec7d6ca60 100644
--- a/arch/arc/boot/dts/axs101.dts
+++ b/arch/arc/boot/dts/axs101.dts
@@ -17,6 +17,6 @@
compatible = "snps,axs101", "snps,arc-sdp";
 
chosen {
-   bootargs = "earlycon=uart8250,mmio32,0xe0022000,115200n8 
console=tty0 console=ttyS3,115200n8 consoleblank=0";
+   bootargs = "earlycon=uart8250,mmio32,0xe0022000,115200n8 
console=tty0 console=ttyS3,115200n8 consoleblank=0 video=1280x720@60";
};
 };
diff --git a/arch/arc/boot/dts/axs103_idu.dts b/arch/arc/boot/dts/axs103_idu.dts
index 070c29782216..5c843d9b4ac8 100644
--- a/arch/arc/boot/dts/axs103_idu.dts
+++ b/arch/arc/boot/dts/axs103_idu.dts
@@ -20,6 +20,6 @@
compatible = "snps,axs103", "snps,arc-sdp";
 
chosen {
-   bootargs = "earlycon=uart8250,mmio32,0xe0022000,115200n8 
console=ttyS3,115200n8 debug print-fatal-signals=1";
+   bootargs = "earlycon=uart8250,mmio32,0xe0022000,115200n8 
console=tty0 console=ttyS3,115200n8 print-fatal-signals=1 consoleblank=0 
video=1280x720@60";
};
 };
diff --git a/arch/arc/configs/axs101_defconfig 
b/arch/arc/configs/axs101_defconfig
index 0a0eaf09aac7..6980b966a364 100644
--- a/arch/arc/configs/axs101_defconfig
+++ b/arch/arc/configs/axs101_defconfig
@@ -75,9 +75,11 @@ CONFIG_I2C=y
 CONFIG_I2C_CHARDEV=y
 CONFIG_I2C_DESIGNWARE_PLATFORM=y
 # CONFIG_HWMON is not set
+CONFIG_DRM=m
+CONFIG_DRM_I2C_ADV7511=m
+CONFIG_DRM_ARCPGU=m
 CONFIG_FB=y
 CONFIG_FRAMEBUFFER_CONSOLE=y
-CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
 CONFIG_LOGO=y
 # CONFIG_LOGO_LINUX_MONO is not set
 # CONFIG_LOGO_LINUX_VGA16 is not set
diff --git a/arch/arc/configs/axs103_smp_defconfig 
b/arch/arc/configs/axs103_smp_defconfig
index 110874705085..30a3d4cf53d2 100644
--- a/arch/arc/configs/axs103_smp_defconfig
+++ b/arch/arc/configs/axs103_smp_defconfig
@@ -77,9 +77,11 @@ CONFIG_I2C=y
 CONFIG_I2C_CHARDEV=y
 CONFIG_I2C_DESIGNWARE_PLATFORM=y
 # CONFIG_HWMON is not set
+CONFIG_DRM=m
+CONFIG_DRM_I2C_ADV7511=m
+CONFIG_DRM_ARCPGU=m
 CONFIG_FB=y
 CONFIG_FRAMEBUFFER_CONSOLE=y
-CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
 CONFIG_LOGO=y
 # CONFIG_LOGO_LINUX_MONO is not set
 # CONFIG_LOGO_LINUX_VGA16 is not set
-- 
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] ARCv2: MCIP: Deprecate setting of affinity in Device Tree

2016-11-22 Thread Marc Zyngier 
Hi Yuriy,

On 14/11/16 14:35, Yuriy Kolerov wrote:
> Hi Marc,
> 
>> -Original Message-
>> From: Marc Zyngier [mailto:marc.zyng...@arm.com]
>> Sent: Friday, November 11, 2016 6:29 PM
>> To: Yuriy Kolerov ; linux-snps-
>> a...@lists.infradead.org
>> Cc: vineet.gup...@synopsys.com; alexey.brod...@synopsys.com;
>> t...@linutronix.de; linux-ker...@vger.kernel.org
>> Subject: Re: [PATCH] ARCv2: MCIP: Deprecate setting of affinity in Device
>> Tree
>>
>> Hi Yuriy,
>>
>> On 11/11/16 14:38, Yuriy Kolerov wrote:
>>> Ignore value of interrupt distribution mode for common interrupts in
>>> IDU since setting of affinity using value from Device Tree is
>>> deprecated in ARC. Originally it is done in idu_irq_xlate() function
>>> and it is semantically wrong and does not guaranty that an affinity
>>> value will be set properly.
>>>
>>> However it is necessary to set a default affinity value manually for
>>> all common interrupts since initially all of them are disabled by IDU
>>> (a CPU mask for common interrupts is set to 0 after CPU reset) and in
>>> some cases the kernel cannot do it itself after initialization of
>>> endpoint devices (e.g. when IRQ chip below of IDU does not support
>>> setting of affinity and it cannot propagate an affinity value to IDU).
>>>
>>> By default send all common interrupts to the first online CPU.
>>> Usually it is a boot CPU. If the kernel is built without support of
>>> SMP then idu_irq_set_affinity() must be called manually since
>>> irq_set_affinity() does nothing in this case.
>>>
>>> Signed-off-by: Yuriy Kolerov 
>>> ---
>>>  .../interrupt-controller/snps,archs-idu-intc.txt   |  3 ++
>>>  arch/arc/kernel/mcip.c | 51 
>>> +-
>>>  2 files changed, 24 insertions(+), 30 deletions(-)
>>>
>>> diff --git
>>> a/Documentation/devicetree/bindings/interrupt-controller/snps,archs-id
>>> u-intc.txt
>>> b/Documentation/devicetree/bindings/interrupt-controller/snps,archs-id
>>> u-intc.txt
>>> index 0dcb7c7..0607bab 100644
>>> ---
>>> a/Documentation/devicetree/bindings/interrupt-controller/snps,archs-id
>>> u-intc.txt
>>> +++ b/Documentation/devicetree/bindings/interrupt-controller/snps,arch
>>> +++ s-idu-intc.txt
>>> @@ -15,6 +15,9 @@ Properties:
>>>Second cell specifies the irq distribution mode to cores
>>>   0=Round Robin; 1=cpu0, 2=cpu1, 4=cpu2, 8=cpu3
>>>
>>> +  The second cell in interrupts property is deprecated and ignored.
>>> + All common  interrupts are sent to the boot CPU core by default.
>>> +
>>
>> 
>> This comment only affects the behaviour of the driver, and not the
>> hardware. I'd rather see something along the lines of:
>>
>> "The second cell is only a hint, and an operating system is free to ignore 
>> it."
>>
>>>intc accessed via the special ARC AUX register interface, hence "reg"
>> property
>>>is not specified.
>>>
>>> diff --git a/arch/arc/kernel/mcip.c b/arch/arc/kernel/mcip.c index
>>> 6d90e4b..f36b8d7 100644
>>> --- a/arch/arc/kernel/mcip.c
>>> +++ b/arch/arc/kernel/mcip.c
>>> @@ -174,7 +174,6 @@ static void idu_irq_unmask(struct irq_data *data)
>>> raw_spin_unlock_irqrestore(_lock, flags);  }
>>>
>>> -#ifdef CONFIG_SMP
>>>  static int
>>>  idu_irq_set_affinity(struct irq_data *data, const struct cpumask
>> *cpumask,
>>>  bool force)
>>> @@ -204,7 +203,6 @@ idu_irq_set_affinity(struct irq_data *data, const
>>> struct cpumask *cpumask,
>>>
>>> return IRQ_SET_MASK_OK;
>>>  }
>>> -#endif
>>>
>>>  static struct irq_chip idu_irq_chip = {
>>> .name   = "MCIP IDU Intc",
>>> @@ -228,9 +226,24 @@ static void idu_cascade_isr(struct irq_desc
>>> *desc)
>>>
>>>  static int idu_irq_map(struct irq_domain *d, unsigned int virq,
>>> irq_hw_number_t hwirq)  {
>>> +   cpumask_t affinity;
>>> +
>>> irq_set_chip_and_handler(virq, _irq_chip, handle_level_irq);
>>> irq_set_status_flags(virq, IRQ_MOVE_PCNTXT);
>>>
>>> +   /* By default send all common interrupts to the first online CPU.
>>> +* Usually it is a boot CPU. If the kernel is built without support
>>> +* of SMP then idu_irq_set_affinity() must be called manually since
>>> +* irq_set_affinity() does nothing in this case.
>>> +*/
>>> +   cpumask_copy(,
>> cpumask_of(cpumask_first(cpu_online_mask)));
>>> +
>>> +#ifdef CONFIG_SMP
>>> +   irq_set_affinity(virq, );
>>
>> Ghhha. Please don't do that. You are now re-entering the IRQ
>> framework, and there is no guarantee that this is safe (what locks are being
>> held???). At that stage, you don't even know if the irq_desc exists yet. And
>> since you're not testing the return value, you can't even know if that 
>> worked.
> 
> However functions like irq_set_chip_and_handler() and
> irq_set_status_flags() which are used above set a lock on irq_desc
> and seems like this structure must exists on this stage. And
> irq_set_affinity() has the same behavior - it locks irq_desc and