Re: Build regressions/improvements in v4.9-rc1

[Thomas Petazzoni]

Hello,

On Wed, 19 Oct 2016 12:23:12 +, Alexey Brodkin wrote:

> > I tried building a new toolchain with buildroot, using the instructions
> > from last time, but the resulting toolchain doesn't relocate, ie. it has
> > hard-coded paths in it. Any ideas?  
> 
> Hm... that's strange - it used to work but doesn't work with newer 
> Buildroot...
> 
> Anyways if something very simple (i.e. with no extra libraries) works for you 
> just go
> ahead and grab pre-built image that Thomas Petazzoni builds.
> 
> That's the most recent one:
> http://autobuild.buildroot.org/toolchains/tarballs/br-arcle-hs38-full-2016.08-613-ge98b4dd.tar.bz2
> 
> If I'm not mistaken Thomas runs some post-processing script to make these 
> toolchains
> relocatable.
> 
> Maybe Thomas may comment on that and even maybe will share his 
> post-processing technique
> so you'll be able to build your customized toolchain.

I simply have two patches on top of Buildroot to build the toolchains
available at http://autobuild.buildroot.org/toolchains/tarballs/ :

 - One patch that builds mpc, gmp and mpfr statically. This is needed
   since the host tools are built with an absolute rpath, so once the
   toolchain is moved, it can't find the host shared libraries that
   have been built for it. Using static linking is a temporary
   work-around, our idea is to fix the rpath to use relative path using
   $ORIGIN. There are some patches from Samuel Martin doing this, we
   have discussed them during the Buildroot Developers Meeting last
   week-end, and we proposed to Samuel to investigate a slightly
   different approach (namely add more features to the upstream
   patchelf utility).

 - One patch that fixes the toolchain wrapper logic so that it works
   fine when the toolchain is moved out of the usr/ sub-directory. We
   started discussing it during the meeting, but I got drowned into
   other discussions, so we haven't had the time to get to the bottom
   of it.

If people are interested, I can prepare a tutorial on how to build
re-usable and relocatable toolchains with Buildroot.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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

Re: [PATCH v2] ARC: Adjust cpuinfo for non-continuous cpu ids

[Vineet Gupta]

On 10/19/2016 04:25 AM, Noam Camus wrote:
> From: Noam Camus 
>
> num_possible_cpus() returns how many CPUs may be present on system.
> However we want the highest possible CPU number.
> This may be differ in a sparsed possible CPUs map.
> Such map achived by OF for plat-eznps.
>
> For example if we have:
> possible cpus mask 0,3
>
> Then:
> num_possible_cpus() is equal 2
>   while
> nr_cpu_ids is equal 4.
>
> Only for value 4 c_start() will provide correct cpuinfo at procfs.

This is much much better. Applied to for-curr !

Thx,
-Vineet

>
> Signed-off-by: Noam Camus 
> ---
>  arch/arc/kernel/setup.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arc/kernel/setup.c b/arch/arc/kernel/setup.c
> index 64907de..bd2e3a4 100644
> --- a/arch/arc/kernel/setup.c
> +++ b/arch/arc/kernel/setup.c
> @@ -512,7 +512,7 @@ static void *c_start(struct seq_file *m, loff_t *pos)
>* way to pass it w/o having to kmalloc/free a 2 byte string.
>* Encode cpu-id as 0xFF, which is decoded by show routine.
>*/
> - return *pos < num_possible_cpus() ? cpu_to_ptr(*pos) : NULL;
> + return *pos < nr_cpu_ids ? cpu_to_ptr(*pos) : NULL;
>  }
>  
>  static void *c_next(struct seq_file *m, void *v, loff_t *pos)


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

Re: Build regressions/improvements in v4.9-rc1

[Alexey Brodkin]

Hi Michael,

On Wed, 2016-10-19 at 22:50 +1100, Michael Ellerman wrote:
> Vineet Gupta  writes:
> > 
> > On 10/17/2016 02:02 PM, Arnd Bergmann wrote:
> > > 
> > > On Monday, October 17, 2016 9:59:24 AM CEST Vineet Gupta wrote:
> > > > 
> > > > On 10/17/2016 12:34 AM, Geert Uytterhoeven wrote:
> > > > > 
> > > > > > 
> > > > > > 48 error regressions:
> > > > > > > 
> > > > > > >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: 
> > > > > > > bad instruction `llockd r2,[r0]':  => 476
> > > > > > >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: 
> > > > > > > bad instruction `llockd r2,[r13]':  =>
> > > > > > > 475
> > > > 
> > > > [snip...]
> > > > 
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: 
> > > > > > > bad instruction `scondd r4,[r8]':  => 516
> > > > > > >   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: 
> > > > > > > bad instruction `scondd r6,[r3]':  => 478
> > > > > arcv2/axs103_smp_defconfig
> > 
> > @Michael can I bother you to upgrade the tools or is this absolutely must 
> > for you.
> 
> Happy to, just short on time.
> 
> I tried building a new toolchain with buildroot, using the instructions
> from last time, but the resulting toolchain doesn't relocate, ie. it has
> hard-coded paths in it. Any ideas?

Hm... that's strange - it used to work but doesn't work with newer Buildroot...

Anyways if something very simple (i.e. with no extra libraries) works for you 
just go
ahead and grab pre-built image that Thomas Petazzoni builds.

That's the most recent one:
http://autobuild.buildroot.org/toolchains/tarballs/br-arcle-hs38-full-2016.08-613-ge98b4dd.tar.bz2

If I'm not mistaken Thomas runs some post-processing script to make these 
toolchains
relocatable.

Maybe Thomas may comment on that and even maybe will share his post-processing 
technique
so you'll be able to build your customized toolchain.

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

Re: Build regressions/improvements in v4.9-rc1

[Michael Ellerman]

Vineet Gupta  writes:
> On 10/17/2016 02:02 PM, Arnd Bergmann wrote:
>> On Monday, October 17, 2016 9:59:24 AM CEST Vineet Gupta wrote:
>>> On 10/17/2016 12:34 AM, Geert Uytterhoeven wrote:
> 48 error regressions:
>>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad 
>> instruction `llockd r2,[r0]':  => 476
>>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad 
>> instruction `llockd r2,[r13]':  => 475
>>>
>>> [snip...]
>>>
>>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad 
>> instruction `scondd r4,[r8]':  => 516
>>   + /home/kisskb/slave/src/arch/arc/include/asm/atomic.h: Error: bad 
>> instruction `scondd r6,[r3]':  => 478
 arcv2/axs103_smp_defconfig
>
> @Michael can I bother you to upgrade the tools or is this absolutely must for 
> you.

Happy to, just short on time.

I tried building a new toolchain with buildroot, using the instructions
from last time, but the resulting toolchain doesn't relocate, ie. it has
hard-coded paths in it. Any ideas?

cheers

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

Re: [PATCH] dmaengine: DW DMAC: split pdata to hardware properties and platform quirks

[Eugeniy Paltsev]

Hi Andy,
On Fri, 2016-10-07 at 14:05 +0300, Andy Shevchenko wrote:
> On Wed, 2016-10-05 at 15:14 +, Eugeniy Paltsev wrote:
> > 
> > Hi Andy,
> > what do you think about these changes?
> I was off for few weeks, will look at this next week.
> 
I was wondering you to tell yours ideas about this patch, if you have
any time for this.

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

[PATCH v2] ARC: Adjust cpuinfo for non-continuous cpu ids

[Noam Camus]

From: Noam Camus 

num_possible_cpus() returns how many CPUs may be present on system.
However we want the highest possible CPU number.
This may be differ in a sparsed possible CPUs map.
Such map achived by OF for plat-eznps.

For example if we have:
possible cpus mask 0,3

Then:
num_possible_cpus() is equal 2
while
nr_cpu_ids is equal 4.

Only for value 4 c_start() will provide correct cpuinfo at procfs.

Signed-off-by: Noam Camus 
---
 arch/arc/kernel/setup.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arc/kernel/setup.c b/arch/arc/kernel/setup.c
index 64907de..bd2e3a4 100644
--- a/arch/arc/kernel/setup.c
+++ b/arch/arc/kernel/setup.c
@@ -512,7 +512,7 @@ static void *c_start(struct seq_file *m, loff_t *pos)
 * way to pass it w/o having to kmalloc/free a 2 byte string.
 * Encode cpu-id as 0xFF, which is decoded by show routine.
 */
-   return *pos < num_possible_cpus() ? cpu_to_ptr(*pos) : NULL;
+   return *pos < nr_cpu_ids ? cpu_to_ptr(*pos) : NULL;
 }
 
 static void *c_next(struct seq_file *m, void *v, loff_t *pos)
-- 
1.7.1


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

RE: [PATCH] ARC: Adjust cpuinfo for non-continuous cpu ids

[Noam Camus]

> From: Vineet Gupta [mailto:vineet.gup...@synopsys.com] 
> Sent: Tuesday, October 18, 2016 8:49 PM

>>
>> num_possible_cpus() returns how many CPUs may be present on system.
>> However we want the highest possible CPU number.
>
>Highest possible number "Detected" at boot ? Can you explain a bit more !

While trying to provide explanation I decided to "rethink" on this patch.
Its effect is not visible to you due to another "local" patch I use which 
justify this patch.
I need to reconsider both patches (maybe I will even remove both of them).

Thanks for the feedback.
Noam 
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

[PATCH v2] drm/arcpgu: Accommodate adv7511 switch to DRM bridge

[Eugeniy Paltsev]

ARC PGU driver starts crashing on initialization after
'commit e12c2f645557 ("drm/i2c: adv7511: Convert to drm_bridge")'
This happenes because in "arcpgu_drm_hdmi_init" function we get pointer
of "drm_i2c_encoder_driver" structure, which doesn't exist after
adv7511 hdmi encoder interface changed from slave encoder to drm bridge.
So, when we call "encoder_init" function from this structure driver
crashes.

Bootlog:
->8
[drm] Initialized drm 1.1.0 20060810
arcpgu e0017000.pgu: arc_pgu ID: 0xabbabaab
arcpgu e0017000.pgu: assigned reserved memory node frame_buffer@9e00
Path: (null)
CPU: 0 PID: 1 Comm: swapper Not tainted 4.8.0-1-gb5642252fa01-dirty #8
task: 9a058000 task.stack: 9a032000

[ECR   ]: 0x00220100 => Invalid Read @ 0x0004 by insn @ 0x803934e8
[EFA   ]: 0x0004
[BLINK ]: drm_atomic_helper_connector_dpms+0xa6/0x230
[ERET  ]: drm_atomic_helper_connector_dpms+0xa4/0x230
[STAT32]: 0x0846 : K DE   E2 E1
BTA: 0x8016d949  SP: 0x9a033e34  FP: 0x
LPS: 0x8036f6fc LPE: 0x8036f700 LPC: 0x
r00: 0x8063c118 r01: 0x805b98ac r02: 0x0b11
r03: 0x r04: 0x9a010f54 r05: 0x
r06: 0x0001 r07: 0x r08: 0x0028
r09: 0x0001 r10: 0x0007 r11: 0x0054
r12: 0x720a3033

Stack Trace:
  drm_atomic_helper_connector_dpms+0xa4/0x230
  arcpgu_drm_hdmi_init+0xbc/0x228
  arcpgu_probe+0x168/0x244
  platform_drv_probe+0x26/0x64
  really_probe+0x1f0/0x32c
  __driver_attach+0xa8/0xd0
  bus_for_each_dev+0x3c/0x74
  bus_add_driver+0xc2/0x184
  driver_register+0x50/0xec
  do_one_initcall+0x3a/0x120
  kernel_init_freeable+0x108/0x1a0
->8

Fix ARC PGU driver to be able work with drm bridge hdmi encoder
interface. The hdmi connector code isn't needed anymore as we expect
the adv7511 bridge driver to create/manage the connector.

Signed-off-by: Eugeniy Paltsev 
---
Changes for v2:
   - remove bridge functions call from kms driver
   - get rid of drm_encoder_slave interface
   - coding style cleanup

 drivers/gpu/drm/arc/arcpgu_hdmi.c | 159 --
 1 file changed, 17 insertions(+), 142 deletions(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_hdmi.c 
b/drivers/gpu/drm/arc/arcpgu_hdmi.c
index b7a8b2a..b69c66b 100644
--- a/drivers/gpu/drm/arc/arcpgu_hdmi.c
+++ b/drivers/gpu/drm/arc/arcpgu_hdmi.c
@@ -14,170 +14,45 @@
  *
  */
 
-#include 
+#include 
 #include 
-#include 
 
 #include "arcpgu.h"
 
-struct arcpgu_drm_connector {
-   struct drm_connector connector;
-   struct drm_encoder_slave *encoder_slave;
-};
-
-static int arcpgu_drm_connector_get_modes(struct drm_connector *connector)
-{
-   const struct drm_encoder_slave_funcs *sfuncs;
-   struct drm_encoder_slave *slave;
-   struct arcpgu_drm_connector *con =
-   container_of(connector, struct arcpgu_drm_connector, connector);
-
-   slave = con->encoder_slave;
-   if (slave == NULL) {
-   dev_err(connector->dev->dev,
-   "connector_get_modes: cannot find slave encoder for 
connector\n");
-   return 0;
-   }
-
-   sfuncs = slave->slave_funcs;
-   if (sfuncs->get_modes == NULL)
-   return 0;
-
-   return sfuncs->get_modes(>base, connector);
-}
-
-static enum drm_connector_status
-arcpgu_drm_connector_detect(struct drm_connector *connector, bool force)
-{
-   enum drm_connector_status status = connector_status_unknown;
-   const struct drm_encoder_slave_funcs *sfuncs;
-   struct drm_encoder_slave *slave;
-
-   struct arcpgu_drm_connector *con =
-   container_of(connector, struct arcpgu_drm_connector, connector);
-
-   slave = con->encoder_slave;
-   if (slave == NULL) {
-   dev_err(connector->dev->dev,
-   "connector_detect: cannot find slave encoder for 
connector\n");
-   return status;
-   }
-
-   sfuncs = slave->slave_funcs;
-   if (sfuncs && sfuncs->detect)
-   return sfuncs->detect(>base, connector);
-
-   dev_err(connector->dev->dev, "connector_detect: could not detect slave 
funcs\n");
-   return status;
-}
-
-static void arcpgu_drm_connector_destroy(struct drm_connector *connector)
-{
-   drm_connector_unregister(connector);
-   drm_connector_cleanup(connector);
-}
-
-static const struct drm_connector_helper_funcs
-arcpgu_drm_connector_helper_funcs = {
-   .get_modes = arcpgu_drm_connector_get_modes,
-};
-
-static const struct drm_connector_funcs arcpgu_drm_connector_funcs = {
-   .dpms = drm_helper_connector_dpms,
-   .reset = drm_atomic_helper_connector_reset,
-   .detect = arcpgu_drm_connector_detect,
-   .fill_modes = drm_helper_probe_single_connector_modes,
-   .destroy = arcpgu_drm_connector_destroy,
-   .atomic_duplicate_state =