Re: [PATCH] arc: get rate from clk driver instead of reading device tree

[Alexey Brodkin]

Hi Vineet,

On Wed, 2017-02-22 at 10:34 -0800, Vineet Gupta wrote:
> On 02/22/2017 02:36 AM, Vlad Zakharov wrote:
> > 
> > We were reading clock rate directly from device tree "clock-frequency"
> > property of corresponding clock node in show_cpuinfo function.
> > 
> > Such approach is correct only in case cpu is always clocked by
> > "fixed-clock". If we use clock driver that allows rate to be changed
> > this won't work as rate may change during the time or even
> > "clock-frequency" property may not be presented at all.
> > 
> > So this commit replaces reading device tree with getting rate from clock
> > driver. This approach is much more flexible and will work for both fixed
> > and mutable clocks.
> > 
> > Signed-off-by: Vlad Zakharov 
> > ---
> >  arch/arc/kernel/setup.c | 6 --
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/arc/kernel/setup.c b/arch/arc/kernel/setup.c
> > index 3093fa8..49b0804 100644
> > --- a/arch/arc/kernel/setup.c
> > +++ b/arch/arc/kernel/setup.c
> > @@ -10,6 +10,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > @@ -488,7 +489,8 @@ static int show_cpuinfo(struct seq_file *m, void *v)
> >  {
> >     char *str;
> >     int cpu_id = ptr_to_cpu(v);
> > -   struct device_node *core_clk = of_find_node_by_name(NULL, "core_clk");
> > +   struct device *cpu_dev = get_cpu_device(cpu_id);
> > +   struct clk *cpu_clk = clk_get(cpu_dev, "core_clk");
> >     u32 freq = 0;
> >  
> >     if (!cpu_online(cpu_id)) {
> > @@ -502,7 +504,7 @@ static int show_cpuinfo(struct seq_file *m, void *v)
> >  
> >     seq_printf(m, arc_cpu_mumbojumbo(cpu_id, str, PAGE_SIZE));
> >  
> > -   of_property_read_u32(core_clk, "clock-frequency", );
> > +   freq = clk_get_rate(cpu_clk);
> >     if (freq)
> >     seq_printf(m, "CPU speed\t: %u.%02u Mhz\n",
> >        freq / 100, (freq / 1) % 100);
> 
> I'm not too familiar with clk API, do u need to clk_put() afterwards ? 
> @Alexey can
> u please check !

I'm not really sure why clk_put() got in the picture here at all.
As it is mentioned here 
http://elixir.free-electrons.com/source/include/linux/clk.h?v=4.10#L305
clk_put() means "free" the clock source.

Anyways this patch alone was not sufficient due to missing changes in .dts 
files and
Vlad is going to send v2 soonish.

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

Re: [PATCH] net: phy: dp83867: Fall-back to default values of clock delay and FIFO depth

[Alexey Brodkin]

Hi Florian,

On Wed, 2017-02-08 at 10:20 -0800, Florian Fainelli wrote:
> On 02/08/2017 10:15 AM, David Miller wrote:
> > 
> > From: Alexey Brodkin <alexey.brod...@synopsys.com>
> > Date: Mon,  6 Feb 2017 22:24:45 +0300
> > 
> > > 
> > > Given there're default values mentioned in the PHY datasheet
> > > fall-back gracefully to them instead of silently return an error
> > > through the whole call-chain.
> > > 
> > > This allows to use minimalistic description in DT if no special
> > > features are required.
> > > 
> > > Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
> > 
> > If these defaults are legitimate to use, then you should probably also
> > set them in the non-CONFIG_OF_MDIO case implementation of
> > dp83867_of_init().
> 
> IIRC this is what Alexey is doing already, in case of errors, instead of
> returning the error code, he changes the default values and does not
> propagate the error code.
> 
> Alexey, you are essentially making dp83867_of_init() impossible to fail
> (or nearly) now, even with invalid properties, so I agree with David
> here, you should probably have a function that runs after
> dp83867_of_init() whose job is to set default values, if none have been
> previously set through Device Tree.

But why do we need to return error code from dp83867_of_init()?
The point is this function doesn't do any hardware setup as well,
in fact it doesn't even reads anything from real hardware.

So we may indeed report an error to above callers (which is not super convenient
because the error comes many levels above without any error message making
understanding of the failure pretty complicated - go trace where it came from)
but what would it mean to a user? What do we want our user to do?
Set at least something in required properties? Then why don't we do that 
ourselves
right in the driver? Moreover since we're talking about defaults mentioned by
the PHY manufacturer we will just use "factory settings". Still allowing others 
to
override defaults with their .dts.

I agree with David that it really worth to do the same settings for 
non_CONFIG_OF_MDIO
case.

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

[PATCH] ARC: [arcompact] fix handling of unaligned access in delay slot

[Alexey Brodkin]

Commit 9aed02feae5 ("ARC: [arcompact] handle unaligned access delay slot
corner case") was meant to fix one corner-case of unaligned access
fixup. But for some reason real implementation has an important spello
which prevents kernel to be built with enabled
CONFIG_ARC_EMUL_UNALIGNED:
->8
arch/arc/kernel/unaligned.c: In function 'misaligned_fixup':
arch/arc/kernel/unaligned.c:246:25: error: expected ';' before '~ token
   regs->ret = regs->bta ~1U;
 ^
->8

What needs to be done - LSB bit of regs->bta has to be cleared and now
we do exactly this with "& ~1U".

While at it fix another spello in comments.

Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
Reported-by: John Crispin <j...@phrozen.org>
Cc: Felix Fietkau <n...@nbd.name>
Cc: Vineet Gupta <vgu...@synopsys.com>
Cc: Igor Guryanov <gurya...@synopsys.com>
---
 arch/arc/kernel/unaligned.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arc/kernel/unaligned.c b/arch/arc/kernel/unaligned.c
index 91ebe382147f..39ee23d107cc 100644
--- a/arch/arc/kernel/unaligned.c
+++ b/arch/arc/kernel/unaligned.c
@@ -241,9 +241,9 @@ int misaligned_fixup(unsigned long address, struct pt_regs 
*regs,
if (state.fault)
goto fault;
 
-   /* clear any remanants of delay slot */
+   /* clear any remnants of delay slot */
if (delay_mode(regs)) {
-   regs->ret = regs->bta ~1U;
+   regs->ret = regs->bta & ~1U;
regs->status32 &= ~STATUS_DE_MASK;
} else {
regs->ret += state.instr_len;
-- 
2.7.4


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

[PATCH] net: phy: dp83867: Fall-back to default values of clock delay and FIFO depth

[Alexey Brodkin]

Given there're default values mentioned in the PHY datasheet
fall-back gracefully to them instead of silently return an error
through the whole call-chain.

This allows to use minimalistic description in DT if no special
features are required.

Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
Cc: Murali Karicheri <m-kariche...@ti.com>
Cc: Sekhar Nori <nsek...@ti.com>
Cc: David S. Miller <da...@davemloft.net>
Cc: Grygorii Strashko <grygorii.stras...@ti.com>
Cc: Florian Fainelli <f.faine...@gmail.com>
Cc: Mugunthan V N <mugunthan...@ti.com>
Cc: Andrew Lunn <and...@lunn.ch>
---
 drivers/net/phy/dp83867.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index ca1b462..5d8c5ec 100644
--- a/drivers/net/phy/dp83867.c
+++ b/drivers/net/phy/dp83867.c
@@ -135,17 +135,20 @@ static int dp83867_of_init(struct phy_device *phydev)
if (ret &&
(phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
 phydev->interface == PHY_INTERFACE_MODE_RGMII_RXID))
-   return ret;
+   dp83867->rx_id_delay = DP83867_RGMIIDCTL_2_00_NS;
 
ret = of_property_read_u32(of_node, "ti,tx-internal-delay",
   >tx_id_delay);
if (ret &&
(phydev->interface == PHY_INTERFACE_MODE_RGMII_ID ||
 phydev->interface == PHY_INTERFACE_MODE_RGMII_TXID))
-   return ret;
+   dp83867->tx_id_delay = DP83867_RGMIIDCTL_2_00_NS;
 
-   return of_property_read_u32(of_node, "ti,fifo-depth",
-  >fifo_depth);
+   ret = of_property_read_u32(of_node, "ti,fifo-depth", 
>fifo_depth);
+   if (ret)
+   dp83867->fifo_depth = DP83867_PHYCR_FIFO_DEPTH_4_B_NIB;
+
+   return 0;
 }
 #else
 static int dp83867_of_init(struct phy_device *phydev)
-- 
2.10.2


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

Re: [PATCH] net: phy: dp83867: Fix for automatically detected PHYs

[Alexey Brodkin]

Hi Florian, all,

On Fri, 2017-02-03 at 10:34 -0800, Florian Fainelli wrote:
> On 02/03/2017 09:30 AM, Alexey Brodkin wrote:
> > 
> > Hi Andrew,
> > 
> > On Fri, 2017-02-03 at 18:10 +0100, Andrew Lunn wrote:
> > > 
> > > On Fri, Feb 03, 2017 at 07:52:37PM +0300, Alexey Brodkin wrote:
> > > > 
> > > > 
> > > > Current implemntation returns ENODEV if device tree node for
> > > > phy is absent. But in reality there're many boards with the one
> > > > and only PHY on board and MACs that may find a PHY by querying
> > > > MDIO bus. One good example is STMMAC.
> > > 
> > > Humm, not so sure about that. That check for an OF node has always
> > > been there, since day one for this driver.
> > > 
> > > What has changed recently is where it looks for these device tree
> > > properties. It used to wrongly look in the MAC node. It was changed to
> > > look in the PHY node. So this is probably the reason you are having
> > > problems.
> > 
> > Well we don't mention PHY node in our device trees because with
> > 1 PHY connected via MDIO bus there's no point in spending electrons
> > on adding extra stuff. 
> 
> That's a terrible justification, you are running Linux on devices, if
> you care about electrons run a tiny RTOS ;)

Agree :)

> > 
> > Well in case if default settings work fine -
> > which up until now was the case for us.
> 
> You should really consider listing your Ethernet PHY as a child node of
> dwmac MDIO bus because that will be a correct and accurate
> representation of the hardware, and if the PHY driver needs specific
> properties to be given (e.g: random TX/RX delays, etc.) that is the only
> way you could communicate those properly to the PHY driver.

Agree here as well, indeed I'm going to update my .dts because
that is supposed to reflect real HW and it will be that way.

But still I'm wondering if that's a must?
In that case we need to update drivers for other PHYs and probably start
from the genphy to align requirements.

Otherwise poor guys like me who switched from one PHY to another will
end up frustrating why stuff that used to work no longer works :)

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

Re: [PATCH] net: phy: dp83867: Fix for automatically detected PHYs

[Alexey Brodkin]

Hi Andrew,

On Fri, 2017-02-03 at 18:10 +0100, Andrew Lunn wrote:
> On Fri, Feb 03, 2017 at 07:52:37PM +0300, Alexey Brodkin wrote:
> > 
> > Current implemntation returns ENODEV if device tree node for
> > phy is absent. But in reality there're many boards with the one
> > and only PHY on board and MACs that may find a PHY by querying
> > MDIO bus. One good example is STMMAC.
> 
> Humm, not so sure about that. That check for an OF node has always
> been there, since day one for this driver.
> 
> What has changed recently is where it looks for these device tree
> properties. It used to wrongly look in the MAC node. It was changed to
> look in the PHY node. So this is probably the reason you are having
> problems.

Well we don't mention PHY node in our device trees because with
1 PHY connected via MDIO bus there's no point in spending electrons
on adding extra stuff. Well in case if default settings work fine -
which up until now was the case for us.

Just in case that's a typical example:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arc/boot/dts/axs10x_mb.dtsi#n58

--->8---
ethernet@0x18000 {
#interrupt-cells = <1>;
compatible = "snps,dwmac";
reg = < 0x18000 0x2000 >;
interrupts = < 4 >;
interrupt-names = "macirq";
phy-mode = "rgmii";
snps,pbl = < 32 >;
clocks = <>;
clock-names = "stmmaceth";
max-speed = <100>;
};
--->8---

This is especially nice because we may change the base-board and use
there another PHY and as long we have drivers for all possible PHY built
in the kernel (or available via modules) proper driver will be instantiated
based on PHY ID read from MDIO. I.e. having no PHY node in DT adds flexibility.

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

[PATCH] net: phy: dp83867: Fix for automatically detected PHYs

[Alexey Brodkin]

Current implemntation returns ENODEV if device tree node for
phy is absent. But in reality there're many boards with the one
and only PHY on board and MACs that may find a PHY by querying
MDIO bus. One good example is STMMAC.

So that's what I saw:
--- Booing --->8-
libphy: Fixed MDIO Bus: probed
stmmaceth f0008000.ethernet: no reset control found
stmmac - user ID: 0x10, Synopsys ID: 0x37
stmmaceth f0008000.ethernet: Ring mode enabled
stmmaceth f0008000.ethernet: DMA HW capability register supported
stmmaceth f0008000.ethernet: Normal descriptors
stmmaceth f0008000.ethernet: RX Checksum Offload Engine supported
stmmaceth f0008000.ethernet: COE Type 2
stmmaceth f0008000.ethernet: TX Checksum insertion supported
stmmaceth f0008000.ethernet: Enable RX Mitigation via HW Watchdog Timer
libphy: stmmac: probed
stmmaceth f0008000.ethernet (unnamed net_device) (uninitialized): PHY ID 
2000a231 at 0 IRQ POLL (stmmac-0:00) active

--- Bringing up eth0 ->8-
Starting network: stmmaceth f0008000.ethernet eth0: device MAC address 
b6:43:6b:1d:50:cf
stmmaceth f0008000.ethernet eth0: Could not attach to PHY
stmmaceth f0008000.ethernet eth0: stmmac_open: Cannot attach to PHY (error: -19)
ip: SIOCSIFFLAGS: No such device
-->8-

Note PHY is detected properly but right after that we're getting -ENODEV.
That makes no sense at all.

So let's silently exit with 0 if there's no DT node for the PHY.
That's what I'm seeing now:
-->8-
Starting network: stmmaceth f0008000.ethernet eth0: device MAC address 
de:1f:a9:f7:8d:88
stmmaceth f0008000.ethernet eth0: fail to init PTP.
IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
udhcpc: started, v1.25.1
udhcpc: sending discover
udhcpc: sending discover
stmmaceth f0008000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off
IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
udhcpc: sending discover
Link is Up - 100/Full
udhcpc: sending select for x.x.x.x
udhcpc: lease of x.x.x.x obtained, lease time 3600
deleting routers
adding dns x.x.x.x
-->8-

Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
Cc: Murali Karicheri <m-kariche...@ti.com>
Cc: Sekhar Nori <nsek...@ti.com>
Cc: David S. Miller <da...@davemloft.net>
Cc: Grygorii Strashko <grygorii.stras...@ti.com>
Cc: Florian Fainelli <f.faine...@gmail.com>
Cc: Mugunthan V N <mugunthan...@ti.com>
Cc: Andrew Lunn <and...@lunn.ch>
---
 drivers/net/phy/dp83867.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/phy/dp83867.c b/drivers/net/phy/dp83867.c
index ca1b462..c44259b 100644
--- a/drivers/net/phy/dp83867.c
+++ b/drivers/net/phy/dp83867.c
@@ -120,7 +120,7 @@ static int dp83867_of_init(struct phy_device *phydev)
int ret;
 
if (!of_node)
-   return -ENODEV;
+   return 0;
 
dp83867->io_impedance = -EINVAL;
 
-- 
2.10.2


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

RE: [PATCH 1/3] arc: vdk: Disable halt on reset

[Alexey Brodkin]

Hi Vineet,

> -Original Message-
> From: Vineet Gupta [mailto:vgu...@synopsys.com]
> Sent: Wednesday, February 1, 2017 10:56 PM
> To: Alexey Brodkin <alexey.brod...@synopsys.com>
> Cc: Ruud Derwig <rder...@synopsys.com>; linux-ker...@vger.kernel.org;
> linux-snps-arc@lists.infradead.org
> Subject: Re: [PATCH 1/3] arc: vdk: Disable halt on reset
> 
> On 02/01/2017 09:52 AM, Alexey Brodkin wrote:
> >> The whole point of adding this to defconfig is to override the default from
> Kconfig ?
> > Not anymore :)
> >
> > Since commit c4c9a040ecb7 ("clocksource: import ARC timer driver"),
> > see
> > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/
> > ?id=c4c9a040ecb7297e011e579f5a9cc280e42d725f
> > we have this:
> > -->8--
> > config ISA_ARCV2
> > bool "ARC ISA v2"
> > select ARC_TIMERS_64BIT
> > -->8--
> >
> > which really means if one selects ISA_ARCV2 then ARC_TIMERS_64BIT gets
> > selected automatically and there's no way to override it from either
> menuconfig or defconfig.
> 
> Bummer - this means VDK based off 4.9+ kernel might be affected with nsim
> GFRC issue !

One note here - I think it only affects 4.10+ kernels.

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

Re: [PATCH 1/3] arc: vdk: Disable halt on reset

[Alexey Brodkin]

Hi Vineet,

On Wed, 2017-02-01 at 09:37 -0800, Vineet Gupta wrote:
> On 02/01/2017 09:14 AM, Alexey Brodkin wrote:
> > 
> > > 
> > > > 
> > > > -# CONFIG_ARC_TIMERS_64BIT is not set
> > > 
> > > Are you sure abut this part. Ater the timers driver rework, this would 
> > > enable GFRC
> > > for SMP builds and AFAIKR there were some issues with time with GFRC + 
> > > nSIM etc..
> > 
> > Not anymore :)
> > 
> > Probably I missed something in discussions.
> 
> STAR 9000879565, 9000879563
> 
> > 
> > As a matter of fact I did run-test resulting vmlinux and it worked very 
> > nice.
> > More over ARC_TIMERS_64BIT is selected automatically by ISA_ARCV2, see
> > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arc/Kconfig#n119
> > 
> > That said even if "# CONFIG_ARC_TIMERS_64BIT is not set" is left in place 
> > the option will be
> > effectively enabled, no?
> 
> The whole point of adding this to defconfig is to override the default from 
> Kconfig ?

Not anymore :)

Since commit c4c9a040ecb7 ("clocksource: import ARC timer driver"),
see 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=c4c9a040ecb7297e011e579f5a9cc280e42d725f
we have this:
-->8--
config ISA_ARCV2
bool "ARC ISA v2"
select ARC_TIMERS_64BIT
-->8--

which really means if one selects ISA_ARCV2 then ARC_TIMERS_64BIT gets selected 
automatically
and there's no way to override it from either menuconfig or defconfig.

Probably behavior that you meant was to keep a separate "config 
ARC_TIMERS_64BIT"
and have it "default y if ISA_ARCV2".

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

Re: [PATCH 0/3] Updates for ARC VDK platform

[Alexey Brodkin]

Hi Vineet,

On Wed, 2017-02-01 at 09:22 -0800, Vineet Gupta wrote:
> On 02/01/2017 09:16 AM, Alexey Brodkin wrote:
> > 
> > Hi Vineet,
> > 
> > On Wed, 2017-02-01 at 09:13 -0800, Vineet Gupta wrote:
> > > 
> > > On 02/01/2017 08:43 AM, Alexey Brodkin wrote:
> > > > 
> > > > This series improves ARC VDK support in upstream Linux kernel by:
> > > >  1) Removal of UP configuration which is no longer supported by ARC VDK.
> > > > Instead SMP platform with all but master cores halted is used to 
> > > > mimic
> > > > UP system.
> > > Is this missing from the series ?
> > Indeed, I was doing 2 things in parallel and so missed -1 patch :(
> > I may either send v2 with missing patch included or save it for another 
> > series
> > that ditches most of UP configs as well. What suits you better?
> 
> Latter would be better !

So then you're going to apply existing series as it is sometime soon and
in the meantime I'll prepare another one, right?

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

Re: [PATCH 0/3] Updates for ARC VDK platform

[Alexey Brodkin]

Hi Vineet,

On Wed, 2017-02-01 at 09:13 -0800, Vineet Gupta wrote:
> On 02/01/2017 08:43 AM, Alexey Brodkin wrote:
> > 
> > This series improves ARC VDK support in upstream Linux kernel by:
> >  1) Removal of UP configuration which is no longer supported by ARC VDK.
> > Instead SMP platform with all but master cores halted is used to mimic
> > UP system.
> 
> Is this missing from the series ?

Indeed, I was doing 2 things in parallel and so missed -1 patch :(
I may either send v2 with missing patch included or save it for another series
that ditches most of UP configs as well. What suits you better?

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

Re: [PATCH 1/3] arc: vdk: Disable halt on reset

[Alexey Brodkin]

Hi Vineet,

On Wed, 2017-02-01 at 08:52 -0800, Vineet Gupta wrote:
> On 02/01/2017 08:42 AM, Alexey Brodkin wrote:
> > 
> > In recent VDKs ARC cores are configured as "run on reset"
> > which made existing kernel configuration outdated to effect that
> > slave cores never start execution of the code keeping only master
> > online.
> > 
> > With that fix we're again in sync with VDK platform.
> > 
> > And while at it we regenerate defconfig via savedefconfig so default
> > options are now excluded.
> > 
> > Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
> > ---
> >  arch/arc/configs/vdk_hs38_smp_defconfig | 4 +---
> >  1 file changed, 1 insertion(+), 3 deletions(-)
> > 
> > diff --git a/arch/arc/configs/vdk_hs38_smp_defconfig 
> > b/arch/arc/configs/vdk_hs38_smp_defconfig
> > index 573028f19de7..f6361de41eec 100644
> > --- a/arch/arc/configs/vdk_hs38_smp_defconfig
> > +++ b/arch/arc/configs/vdk_hs38_smp_defconfig
> > @@ -15,7 +15,7 @@ CONFIG_ARC_PLAT_AXS10X=y
> >  CONFIG_AXS103=y
> >  CONFIG_ISA_ARCV2=y
> >  CONFIG_SMP=y
> > -# CONFIG_ARC_TIMERS_64BIT is not set
> 
> Are you sure abut this part. Ater the timers driver rework, this would enable 
> GFRC
> for SMP builds and AFAIKR there were some issues with time with GFRC + nSIM 
> etc..

Not anymore :)

Probably I missed something in discussions.
As a matter of fact I did run-test resulting vmlinux and it worked very nice.
More over ARC_TIMERS_64BIT is selected automatically by ISA_ARCV2, see
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arc/Kconfig#n119

That said even if "# CONFIG_ARC_TIMERS_64BIT is not set" is left in place the 
option will be
effectively enabled, no?

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

[PATCH 3/3] arc: vdk: Add support of UIO

[Alexey Brodkin]

ARC VDK for EVSS uses UIO for communication with Embedded Vision
Subsystem.

Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
---
 arch/arc/boot/dts/vdk_axs10x_mb.dtsi| 8 
 arch/arc/configs/vdk_hs38_smp_defconfig | 2 ++
 2 files changed, 10 insertions(+)

diff --git a/arch/arc/boot/dts/vdk_axs10x_mb.dtsi 
b/arch/arc/boot/dts/vdk_axs10x_mb.dtsi
index 1953914b9f4f..f0df59b23e21 100644
--- a/arch/arc/boot/dts/vdk_axs10x_mb.dtsi
+++ b/arch/arc/boot/dts/vdk_axs10x_mb.dtsi
@@ -112,5 +112,13 @@
interrupts = <7>;
bus-width = <4>;
};
+
+   /* Embedded Vision subsystem UIO mappings; only relevant for EV 
VDK */
+   uio_ev: uio@0xD000 {
+   compatible = "generic-uio";
+   reg = <0xD000 0x2000 0xD100 0x2000 0x9000 
0x1000 0xC000 0x1000>;
+   reg-names = "ev_gsa", "ev_ctrl", "ev_shared_mem", 
"ev_code_mem";
+   interrupts = <23>;
+   };
};
 };
diff --git a/arch/arc/configs/vdk_hs38_smp_defconfig 
b/arch/arc/configs/vdk_hs38_smp_defconfig
index e03413fbc784..1a9b19903c9a 100644
--- a/arch/arc/configs/vdk_hs38_smp_defconfig
+++ b/arch/arc/configs/vdk_hs38_smp_defconfig
@@ -81,6 +81,8 @@ CONFIG_MMC=y
 CONFIG_MMC_SDHCI=y
 CONFIG_MMC_SDHCI_PLTFM=y
 CONFIG_MMC_DW=y
+CONFIG_UIO=y
+CONFIG_UIO_PDRV_GENIRQ=y
 # CONFIG_IOMMU_SUPPORT is not set
 CONFIG_EXT3_FS=y
 CONFIG_MSDOS_FS=y
-- 
2.7.4


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

[PATCH 2/3] arc: vdk: Add support of MMC controller

[Alexey Brodkin]

ARC VDK virtual platform emulates host MMC controller (DW Mobile Storage)
and moreover rootfs is situated on that virtual card.

Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
---
 arch/arc/boot/dts/vdk_axs10x_mb.dtsi| 18 ++
 arch/arc/configs/vdk_hs38_smp_defconfig |  4 
 2 files changed, 22 insertions(+)

diff --git a/arch/arc/boot/dts/vdk_axs10x_mb.dtsi 
b/arch/arc/boot/dts/vdk_axs10x_mb.dtsi
index 99498a4b4216..1953914b9f4f 100644
--- a/arch/arc/boot/dts/vdk_axs10x_mb.dtsi
+++ b/arch/arc/boot/dts/vdk_axs10x_mb.dtsi
@@ -23,6 +23,12 @@
#clock-cells = <0>;
};
 
+   mmcclk: mmcclk {
+   compatible = "fixed-clock";
+   clock-frequency = <5000>;
+   #clock-cells = <0>;
+   };
+
pguclk: pguclk {
#clock-cells = <0>;
compatible = "fixed-clock";
@@ -94,5 +100,17 @@
interrupts = <5>;
interrupt-names = "arc_ps2_irq";
};
+
+   mmc@0x15000 {
+   compatible = "snps,dw-mshc";
+   reg = <0x15000 0x400>;
+   num-slots = <1>;
+   fifo-depth = <1024>;
+   card-detect-delay = <200>;
+   clocks = <>, <>;
+   clock-names = "biu", "ciu";
+   interrupts = <7>;
+   bus-width = <4>;
+   };
};
 };
diff --git a/arch/arc/configs/vdk_hs38_smp_defconfig 
b/arch/arc/configs/vdk_hs38_smp_defconfig
index f6361de41eec..e03413fbc784 100644
--- a/arch/arc/configs/vdk_hs38_smp_defconfig
+++ b/arch/arc/configs/vdk_hs38_smp_defconfig
@@ -77,6 +77,10 @@ CONFIG_USB_OHCI_HCD=y
 CONFIG_USB_OHCI_HCD_PLATFORM=y
 CONFIG_USB_STORAGE=y
 CONFIG_USB_SERIAL=y
+CONFIG_MMC=y
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_PLTFM=y
+CONFIG_MMC_DW=y
 # CONFIG_IOMMU_SUPPORT is not set
 CONFIG_EXT3_FS=y
 CONFIG_MSDOS_FS=y
-- 
2.7.4


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

[PATCH 1/3] arc: vdk: Disable halt on reset

[Alexey Brodkin]

In recent VDKs ARC cores are configured as "run on reset"
which made existing kernel configuration outdated to effect that
slave cores never start execution of the code keeping only master
online.

With that fix we're again in sync with VDK platform.

And while at it we regenerate defconfig via savedefconfig so default
options are now excluded.

Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
---
 arch/arc/configs/vdk_hs38_smp_defconfig | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/arc/configs/vdk_hs38_smp_defconfig 
b/arch/arc/configs/vdk_hs38_smp_defconfig
index 573028f19de7..f6361de41eec 100644
--- a/arch/arc/configs/vdk_hs38_smp_defconfig
+++ b/arch/arc/configs/vdk_hs38_smp_defconfig
@@ -15,7 +15,7 @@ CONFIG_ARC_PLAT_AXS10X=y
 CONFIG_AXS103=y
 CONFIG_ISA_ARCV2=y
 CONFIG_SMP=y
-# CONFIG_ARC_TIMERS_64BIT is not set
+# CONFIG_ARC_SMP_HALT_ON_RESET is not set
 CONFIG_ARC_UBOOT_SUPPORT=y
 CONFIG_ARC_BUILTIN_DTB_NAME="vdk_hs38_smp"
 CONFIG_PREEMPT=y
@@ -56,7 +56,6 @@ CONFIG_NATIONAL_PHY=y
 CONFIG_MOUSE_PS2_TOUCHKIT=y
 CONFIG_SERIO_ARC_PS2=y
 # CONFIG_LEGACY_PTYS is not set
-# CONFIG_DEVKMEM is not set
 CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
 CONFIG_SERIAL_8250_DW=y
@@ -80,7 +79,6 @@ CONFIG_USB_STORAGE=y
 CONFIG_USB_SERIAL=y
 # CONFIG_IOMMU_SUPPORT is not set
 CONFIG_EXT3_FS=y
-CONFIG_EXT4_FS=y
 CONFIG_MSDOS_FS=y
 CONFIG_VFAT_FS=y
 CONFIG_NTFS_FS=y
-- 
2.7.4


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

[PATCH 0/3] Updates for ARC VDK platform

[Alexey Brodkin]

This series improves ARC VDK support in upstream Linux kernel by:
 1) Removal of UP configuration which is no longer supported by ARC VDK.
Instead SMP platform with all but master cores halted is used to mimic
UP system.

 2) Adding off-the-tree patches that enable MMC card and UIO

Alexey Brodkin (3):
  arc: vdk: Disable halt on reset
  arc: vdk: Add support of MMC controller
  arc: vdk: Add support of UIO

 arch/arc/boot/dts/vdk_axs10x_mb.dtsi| 26 ++
 arch/arc/configs/vdk_hs38_smp_defconfig | 10 +++---
 2 files changed, 33 insertions(+), 3 deletions(-)

-- 
2.7.4


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

Re: stmmac: GMAC_RGSMIIIS reports bogus values

[Alexey Brodkin]

Hi Giuseppe,

On Tue, 2017-01-31 at 10:55 +0100, Giuseppe CAVALLARO wrote:
> On 1/27/2017 11:23 AM, Alexey Brodkin wrote:
> > 
> > That's why my initial proposal was to ignore whatever we read from this 
> > register
> > if we have MDIO bus instantiated already.
> 
> sorry for my late reply, I agree with this approach, according to the
> HW and platform configuration the driver has to understand and then
> work to use either SMA or PCS module.

I already submitted another solution which IMHO is much cleaner and appropriate,
see David has it already in master tree here:
http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=0a764db103376cf69d04449b10688f3516cc0b88

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

Re: stmmac: GMAC_RGSMIIIS reports bogus values

[Alexey Brodkin]

Hi Giuseppe,

On Wed, 2017-01-25 at 21:39 +0300, Alexey Brodkin wrote:
> Hi Giuseppe,
> 
> On Mon, 2016-11-14 at 09:14 +0100, Giuseppe CAVALLARO wrote:
> > 
> > Hello Alexey
> > 
> > Sorry for my late reply. In that case, I think that the stmmac
> > is using own RGMII/SGMII support (PCS) to dialog with the
> > transceiver. I think, from the HW capability register
> > this feature is present and the driver is using it as default.
> 
> Yep looks like that.

Hm, so I took a look at what am I reading from
"Register 22 (HW Feature Register)" in dwmac1000_get_hw_feature()
and was really surprised to see the register value = 0x100509bf.

See bit 6 "PCSSEL" is zeroed which stands for
"PCS registers (TBI, SGMII, or RTBI PHY interface)".

I.e. PCS doesn't exist in our GMAC so most of the previous comments
below should be discarded.

> > I kindly ask you to verify if this is your setup or if you
> > do not want to use it. In that case, it is likely we need to
> > add some code in the driver.
> 
> Well GMAC's databook says:
> --->8--
> The DWC_gmac provides an IEEE 802.3z compliant 10-bit
> Physical Coding Sublayer (PCS) interface that you can use
> when the MAC is configured for the TBI, RTBI, or SGMII PHY
> interface.
> 
> ...
> 
> You can include the optional PCS module in the DWC_gmac by
> selecting the TBI, RTBI, or SGMII interface in coreConsultant
> during configuration.
> --->8--
> 
> But we use RGMII for communication with the PHY.
> And from the quote above I would conclude that for RGMII we should
> have PCS excluded from GMAC.
> 
> I just sent email to GMAC developers here in Synopsys and
> hopefully will get some clarifications from them soon.
> 
> Probably correct solution is as simple as:
> --->8--
> diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
> b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> index a276a32d57f2..f4b67dc7d530 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
> @@ -803,13 +803,7 @@ static void stmmac_check_pcs_mode(struct stmmac_priv 
> *priv)
> int interface = priv->plat->interface;
>  
> if (priv->dma_cap.pcs) {
> -   if ((interface == PHY_INTERFACE_MODE_RGMII) ||
> -   (interface == PHY_INTERFACE_MODE_RGMII_ID) ||
> -   (interface == PHY_INTERFACE_MODE_RGMII_RXID) ||
> -   (interface == PHY_INTERFACE_MODE_RGMII_TXID)) {
> -   netdev_dbg(priv->dev, "PCS RGMII support enabled\n");
> -   priv->hw->pcs = STMMAC_PCS_RGMII;
> -   } else if (interface == PHY_INTERFACE_MODE_SGMII) {
> +   if (interface == PHY_INTERFACE_MODE_SGMII) {
> netdev_dbg(priv->dev, "PCS SGMII support enabled\n");
> priv->hw->pcs = STMMAC_PCS_SGMII;
> }
> --->8--
> 
> > 
> > Also I wonder if, other version of the stmmac worked on this platform
> > before.
> 
> It did work and still works. The only problem is we're getting
> a lot of noise now about bogus link status change. That's because
> this info is now in pr_info() compared to being previously in pr_debug().

So it all really boils down to the following problem:
Link state reported via "Register 54 (SGMII/RGMII/SMII Control and Status 
Register)"
doesn't match status read via MDIO from the PHY.

That's why my initial proposal was to ignore whatever we read from this register
if we have MDIO bus instantiated already.

-Alexey

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

Re: stmmac: GMAC_RGSMIIIS reports bogus values

[Alexey Brodkin]

Hi Giuseppe,

On Mon, 2016-11-14 at 09:14 +0100, Giuseppe CAVALLARO wrote:
> Hello Alexey
> 
> Sorry for my late reply. In that case, I think that the stmmac
> is using own RGMII/SGMII support (PCS) to dialog with the
> transceiver. I think, from the HW capability register
> this feature is present and the driver is using it as default.

Yep looks like that.

> I kindly ask you to verify if this is your setup or if you
> do not want to use it. In that case, it is likely we need to
> add some code in the driver.

Well GMAC's databook says:
--->8--
The DWC_gmac provides an IEEE 802.3z compliant 10-bit
Physical Coding Sublayer (PCS) interface that you can use
when the MAC is configured for the TBI, RTBI, or SGMII PHY
interface.

...

You can include the optional PCS module in the DWC_gmac by
selecting the TBI, RTBI, or SGMII interface in coreConsultant
during configuration.
--->8--

But we use RGMII for communication with the PHY.
And from the quote above I would conclude that for RGMII we should
have PCS excluded from GMAC.

I just sent email to GMAC developers here in Synopsys and
hopefully will get some clarifications from them soon.

Probably correct solution is as simple as:
--->8--
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index a276a32d57f2..f4b67dc7d530 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -803,13 +803,7 @@ static void stmmac_check_pcs_mode(struct stmmac_priv *priv)
int interface = priv->plat->interface;
 
if (priv->dma_cap.pcs) {
-   if ((interface == PHY_INTERFACE_MODE_RGMII) ||
-   (interface == PHY_INTERFACE_MODE_RGMII_ID) ||
-   (interface == PHY_INTERFACE_MODE_RGMII_RXID) ||
-   (interface == PHY_INTERFACE_MODE_RGMII_TXID)) {
-   netdev_dbg(priv->dev, "PCS RGMII support enabled\n");
-   priv->hw->pcs = STMMAC_PCS_RGMII;
-   } else if (interface == PHY_INTERFACE_MODE_SGMII) {
+   if (interface == PHY_INTERFACE_MODE_SGMII) {
netdev_dbg(priv->dev, "PCS SGMII support enabled\n");
priv->hw->pcs = STMMAC_PCS_SGMII;
}
--->8--

> Also I wonder if, other version of the stmmac worked on this platform
> before.

It did work and still works. The only problem is we're getting
a lot of noise now about bogus link status change. That's because
this info is now in pr_info() compared to being previously in pr_debug().

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

[PATCH] ARC: fix allnoconfig builds

[Alexey Brodkin]

In case of allnoconfig HAVE_MOD_ARCH_SPECIFIC=no
because ARC_DW2_UNWIND=no as well.

This enables default "struct mod_arch_specific" from
./include/asm-generic/module.h which clashes with ARC's one.

Before e514943bbfe1 ("ARC: module: Fix !CONFIG_ARC_DW2_UNWIND builds")
ARC's "struct mod_arch_specific" was hidden for !CONFIG_ARC_DW2_UNWIND
builds but not anymore.

So to make our life easier and escape more complicated ifdeffed constructions in
sources let's unconditionally select CONFIG_HAVE_MOD_ARCH_SPECIFIC for ARC.

Reported-by: Anton Kolesov <akole...@synopsys.com>
Fixes: e514943bbfe1 ("ARC: module: Fix !CONFIG_ARC_DW2_UNWIND builds")
Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
---
 arch/arc/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index c75d290..283099c 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -29,7 +29,7 @@ config ARC
select HAVE_KPROBES
select HAVE_KRETPROBES
select HAVE_MEMBLOCK
-   select HAVE_MOD_ARCH_SPECIFIC if ARC_DW2_UNWIND
+   select HAVE_MOD_ARCH_SPECIFIC
select HAVE_OPROFILE
select HAVE_PERF_EVENTS
select HANDLE_DOMAIN_IRQ
-- 
2.10.2


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

RE: [PATCH 4/4] ARCv2: smp-boot: MCIP: use Inter-Core-Debug unit to kick start non master cpus

[Alexey Brodkin]

Hi Vineet,

> -Original Message-
> From: Vineet Gupta
> Sent: Monday, January 16, 2017 11:58 PM
> To: linux-snps-arc@lists.infradead.org; Alexey Brodkin
> <abrod...@synopsys.com>
> Cc: linux-ker...@vger.kernel.org; Vineet Gupta <vgu...@synopsys.com>
> Subject: [PATCH 4/4] ARCv2: smp-boot: MCIP: use Inter-Core-Debug unit to
> kick start non master cpus
> 
> This essentially converts a run-on-reset to halt-on-reset - so non masters 
> self
> halt in early boot code. And later they are resumed from halted PC using
> MCIP ICD assist.
> 
> As mentioned in prev commits, this paves way for radio silence on coherency
> unit, while master is setting up IOC and such.
> 
> Signed-off-by: Vineet Gupta <vgu...@synopsys.com>
> ---
>  arch/arc/include/asm/mcip.h |  1 +
>  arch/arc/kernel/mcip.c  | 31 +++
>  2 files changed, 32 insertions(+)
> 
> diff --git a/arch/arc/include/asm/mcip.h b/arch/arc/include/asm/mcip.h
> index c8fbe4114bad..a6ae4363c388 100644
> --- a/arch/arc/include/asm/mcip.h
> +++ b/arch/arc/include/asm/mcip.h
> @@ -36,6 +36,7 @@ struct mcip_cmd {
>  #define CMD_SEMA_CLAIM_AND_READ  0x11
>  #define CMD_SEMA_RELEASE 0x12
> 
> +#define CMD_DEBUG_RUN0x33
>  #define CMD_DEBUG_SET_MASK   0x34
>  #define CMD_DEBUG_SET_SELECT 0x36
> 
> diff --git a/arch/arc/kernel/mcip.c b/arch/arc/kernel/mcip.c index
> 933382e0edd0..0a1822d2fe52 100644
> --- a/arch/arc/kernel/mcip.c
> +++ b/arch/arc/kernel/mcip.c
> @@ -103,12 +103,43 @@ static void mcip_probe_n_setup(void)
>   cpuinfo_arc700[0].extn.gfrc = mp.gfrc;  }
> 
> +static void __init mcip_cpu_wait(int cpu) {

Has this one passed checkpatch? Above "{" on the same line as function name
and closing one merged with the previous line look strange.

At least here it is said that way:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-style.rst#n129

> + struct mcip_bcr mp;
> +
> + READ_BCR(ARC_REG_MCIP_BCR, mp);
> +
> + /*
> +  * self halt for waiting as Master will resume us using MCIP ICD assist
> +  * Note: if ICD is not configured, we are hosed, but panic here is
> +  *   not going to help as UART access might not even work
> +  */
> + if (mp.dbg)
> + asm volatile("flag 1\n");

Are you sure that won't trigger MDB stop?
I would imagine if MDB saw coreX running and then it unexpectedly [for MDB] 
gets halted
MDB stops, no? Essentially I'm talking about properly set CPMD session.

I have no board handy ATM so just thinking out loud.

> +}
> +
> +static void __init mcip_cpu_kick(int cpu, unsigned long pc) {
> + struct mcip_bcr mp;
> +
> + READ_BCR(ARC_REG_MCIP_BCR, mp);
> +
> + if (mp.dbg)
> + __mcip_cmd_data(CMD_DEBUG_RUN, 0, (1 << cpu));
> + else
> + panic("SMP boot issues: MCIP lacks ICD\n"); }
> +
>  struct plat_smp_ops plat_smp_ops = {
>   .info   = smp_cpuinfo_buf,
>   .init_early_smp = mcip_probe_n_setup,
>   .init_per_cpu   = mcip_setup_per_cpu,
>   .ipi_send   = mcip_ipi_send,
>   .ipi_clear  = mcip_ipi_clear,
> + .cpu_kick   = mcip_cpu_kick,
> +#ifndef CONFIG_ARC_SMP_HALT_ON_RESET

I really hate compile-time defined stuff and would prefer to remove most of that
stuff at least in ARC code instaed of adding more items that stops us from using
the same binary on wider range of ARC cores.

In 2/4 you already do check if core was configured [actually Linux kernel was 
configured but not the HW]
-->8-
if (IS_ENABLED(CONFIG_ARC_SMP_HALT_ON_RESET))
-->8-
so "plat_smp_ops.cpu_wait(cpu)" won't be executed anyways.

> + .cpu_wait   = mcip_cpu_wait,
> +#endif
>  };

So why don't we implement it all much simpler regardless 
CONFIG_ARC_SMP_HALT_ON_RESET?
Like that:
-->8-
static void __init mcip_cpu_wait(int cpu)
{
struct mcip_bcr mp;

/* Check if master has already set "wake_flag" wanting us to run */
if (wake_flag != cpu) { // or similar construction if we switch to 
bitfield

READ_BCR(ARC_REG_MCIP_BCR, mp);

/*
 * self halt for waiting as Master will resume us using MCIP 
ICD assist
 * Note: if ICD is not configured, we are hosed, but panic here 
is
 *   not going to help as UART access might not even work
 */
if (mp.dbg)
asm volatile("flag 1\n");
  

RE: [PATCH 2/4] ARC: smp-boot: run-on-reset: add callback to allow non masters to wait

[Alexey Brodkin]

Hi Vineet,

> -Original Message-
> From: Vineet Gupta
> Sent: Monday, January 16, 2017 11:58 PM
> To: linux-snps-arc@lists.infradead.org; Alexey Brodkin
> <abrod...@synopsys.com>
> Cc: linux-ker...@vger.kernel.org; Vineet Gupta <vgu...@synopsys.com>
> Subject: [PATCH 2/4] ARC: smp-boot: run-on-reset: add callback to allow non
> masters to wait
> 
> Currently for halt-on-reset, non masters spin on a shared memory which is
> wiggled by Master at right time. This is not efficient when hardware support
> exists to stop and resume them from Master (using an external IP block).
> More importantly Master might be setting up SLC or IO-Coherency aperutes
> in early boot duting which other cores need NOT perturb the coherency unit,
> thus need a mechanism that doesn't rely on polling memory.
> 
> This just adds infrastructure for next patch which will add the hardware
> support (MCIP Inter Core Debug Unit).
> 
> Signed-off-by: Vineet Gupta <vgu...@synopsys.com>
> ---
>  arch/arc/include/asm/smp.h |  3 +++
>  arch/arc/kernel/smp.c  | 17 +
>  2 files changed, 16 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arc/include/asm/smp.h b/arch/arc/include/asm/smp.h index
> 0861007d9ef3..6187b9d14b03 100644
> --- a/arch/arc/include/asm/smp.h
> +++ b/arch/arc/include/asm/smp.h
> @@ -50,6 +50,8 @@ extern int smp_ipi_irq_setup(int cpu,
> irq_hw_number_t hwirq);
>   *   mach_desc->init_early()
>   * @init_per_cpu:Called for each core so SMP h/w block driver can do
>   *   any needed setup per cpu (e.g. IPI request)
> + * @cpu_wait:Non masters wait to be resumed later by
> master (to avoid
> + *   perturbing SLC / cache coherency in early boot)
>   * @cpu_kick:For Master to kickstart a cpu (optionally at a 
> PC)
>   * @ipi_send:To send IPI to a @cpu
>   * @ips_clear:   To clear IPI received at @irq
> @@ -58,6 +60,7 @@ struct plat_smp_ops {
>   const char  *info;
>   void(*init_early_smp)(void);
>   void(*init_per_cpu)(int cpu);
> + void(*cpu_wait)(int cpu);
>   void(*cpu_kick)(int cpu, unsigned long pc);
>   void(*ipi_send)(int cpu);
>   void(*ipi_clear)(int irq);
> diff --git a/arch/arc/kernel/smp.c b/arch/arc/kernel/smp.c index
> 44a0d21ed342..e60c11b8f4b9 100644
> --- a/arch/arc/kernel/smp.c
> +++ b/arch/arc/kernel/smp.c
> @@ -96,16 +96,25 @@ static void arc_default_smp_cpu_kick(int cpu,
> unsigned long pc)
>   wake_flag = cpu;
>  }
> 
> +static void arc_default_smp_wait_to_boot(int cpu) {
> + while (wake_flag != cpu)
> + ;
> +
> + wake_flag = 0;

Why don't we convert "wake_flag" into bit-field so each core uses its special 
bit.
It is IMHO beneficial for 2 reasons:
 1. If we ever decide to have master core with ARCID != 0 implementation of 
that procedure won't change,
because "wake_flag" for core with ARCID=0 will be 1 but not 0, see for 
example http://patchwork.ozlabs.org/patch/703645/

 2. There's no need in resetting "wake_flag" to 0 at all as well because each 
core has its own bit and they not affect anybody else.
And in that case ...

> +}
> +
>  void arc_platform_smp_wait_to_boot(int cpu)  {
>   /* for halt-on-reset, we've waited already */
>   if (IS_ENABLED(CONFIG_ARC_SMP_HALT_ON_RESET))
>   return;

...we may just remove above part. Master core by that time has already set our 
bit in "wake_flag" so we
will effectively fall through the following "while".

> - while (wake_flag != cpu)
> - ;

-Alexey


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

RE: [PATCH 3/4] ARCv2: smp: MCIP: remove debug aid to halt all cores when one halts

[Alexey Brodkin]

Hi Vineet,

> -Original Message-
> From: Vineet Gupta
> Sent: Monday, January 16, 2017 11:58 PM
> To: linux-snps-arc@lists.infradead.org; Alexey Brodkin
> <abrod...@synopsys.com>
> Cc: linux-ker...@vger.kernel.org; Vineet Gupta <vgu...@synopsys.com>
> Subject: [PATCH 3/4] ARCv2: smp: MCIP: remove debug aid to halt all cores
> when one halts
> 
> This was really usefull when doing initial bringup and also for occassional
> debug of software and hardware bugs. However in the new smp-boot
> regime, non masters will "self" halt even for run-on-reset configs. This will
> misinteract with the debug feature as in even master will get halted when
> the non masters self halt.
> 
> Signed-off-by: Vineet Gupta <vgu...@synopsys.com>
> ---
>  arch/arc/kernel/mcip.c | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/arch/arc/kernel/mcip.c b/arch/arc/kernel/mcip.c index
> f39142acc89e..933382e0edd0 100644
> --- a/arch/arc/kernel/mcip.c
> +++ b/arch/arc/kernel/mcip.c
> @@ -101,11 +101,6 @@ static void mcip_probe_n_setup(void)
>   IS_AVAIL1(mp.gfrc, "GFRC"));
> 
>   cpuinfo_arc700[0].extn.gfrc = mp.gfrc;
> -
> - if (mp.dbg) {
> - __mcip_cmd_data(CMD_DEBUG_SET_SELECT, 0, 0xf);
> - __mcip_cmd_data(CMD_DEBUG_SET_MASK, 0xf, 0xf);
> - }
>  }

I've been doing that for quite some time locally because that used to be a must
for execution of SMP vmlinux in "pseudo"-UP mode, i.e. on SMP hardware but
with only 1 core being used.

I'm really happy to see this commit upstream - will definitely make life a bit 
simpler.

-Alexey


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

Re: [PATCH 1/2] arc: rename xCCM sections so they are not merged in global .data/.text

[Alexey Brodkin]

Hi Vineet,

On Thu, 2016-12-22 at 16:25 -0800, Vineet Gupta wrote:
> On 12/22/2016 06:09 AM, Alexey Brodkin wrote:
> > diff --git a/arch/arc/include/asm/linkage.h b/arch/arc/include/asm/linkage.h
> > index b29f1a9fd6f7..3a5f13d65ee1 100644
> > --- a/arch/arc/include/asm/linkage.h
> > +++ b/arch/arc/include/asm/linkage.h
> > @@ -28,7 +28,7 @@
> >  /* annotation for data we want in DCCM - if enabled in .config */
> >  .macro ARCFP_CODE
> >  #ifdef CONFIG_ARC_HAS_ICCM
> > -   .section .text.arcfp, "ax",@progbits
> > +   .section .text..arcfp, "ax",@progbits
> 
> Why not turn this around and call it arcfp.text and arcfp.data etc - just like
> done for other special sections such as sched, cpuidle, lock... Just so we are
> consistent with normal kernel convention !

Right that looks much better!
Will do so in v2.

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

Re: [PATCH 2/2] arc: Fix xCCM size check

[Alexey Brodkin]

Hi Vineet,

On Thu, 2016-12-22 at 16:34 -0800, Vineet Gupta wrote:
> On 12/22/2016 06:09 AM, Alexey Brodkin wrote:
> > 
> > CONFIG_ARC_ICCM_SZ in menuconfig is specified in kB while
> > "cpu->Xccm.sz" contains value in bytes thus direct comparison fails
> > leading to boot-time panic like that:
> > --->8-
> > IDENTITY: ARCVER [0x52] ARCNUM [0x1] CHIPID [ 0x0]
> > processor [1]   : ARC HS38 R2.1 (ARCv2 ISA)
> > Timers  : Timer0 Timer1 Local-64-bit-Ctr (not used)
> > ISA Extn: atomic ll64 unalign (not used)
> > : mpy[opt 9] div_rem norm barrel-shift swap minmax swape
> > BPU : full match, cache:2048, Predict Table:16384
> > MMU [v0]: 0k PAGE, JTLB 0 (0x0), uDTLB 0, uITLB 0
> > I-Cache : N/A
> > D-Cache : N/A
> > Peripherals : 0xf000, IO-Coherency (disabled)
> > Vector Table: 0x8000
> > FPU : SP DP
> > DEBUG   : ActionPoint smaRT RTT
> > Extn [CCM]  : DCCM @ e000, 256 KB / ICCM: @ 6000, 256 KB
> > OS ABI [v4] : 64-bit data any register aligned
> > Extn [SMP]  : ARConnect (v2): 2 cores with IPI IDU DEBUG GFRC
> > Kernel panic - not syncing: Linux built with incorrect DCCM Size
> > 
> > ---[ end Kernel panic - not syncing: Linux built with incorrect DCCM Size
> > --->8-
> > 
> > Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
> > Cc: Igor Guryanov <gurya...@synopsys.com>
> > Cc: sta...@vger.kernel.org
> > ---
> >  arch/arc/kernel/setup.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/arc/kernel/setup.c b/arch/arc/kernel/setup.c
> > index ee574f37f365..601dab6fe5e0 100644
> > --- a/arch/arc/kernel/setup.c
> > +++ b/arch/arc/kernel/setup.c
> > @@ -333,12 +333,12 @@ static void arc_chk_core_config(void)
> >     if ((unsigned int)__arc_dccm_base != cpu->dccm.base_addr)
> >     panic("Linux built with incorrect DCCM Base address\n");
> >  
> > -   if (CONFIG_ARC_DCCM_SZ != cpu->dccm.sz)
> > +   if (CONFIG_ARC_DCCM_SZ != TO_KB(cpu->dccm.sz))
> 
> Could we just avoid this existing TO_KB non sense in multiple places by 
> keeping
> the *ccm.sz unit consistent with CONFIG_ARC_*CCM_SZ ?
> so
> -cpu->iccm.sz = 4096 << iccm.sz;/* 8K to 512K */
> +cpu->iccm.sz = 4 << iccm.sz;/* 8K to 512K */
> 
> Since we only want to keep ccm size to kb granularity
> 
> And while at it, rename @sz placeholder in bcr_(i|d)ccm_arc(v2,compact) to 
> sz_k

Well when I started to look at that I understood that in case of ARCv2 smallest
xCCM is 512 bytes which won't fit in our 1kB grained solution.

So it looks like instead of moving to "sz_k" we have to stay with what we have
and moreover add support of that 512 byte corner-case becase TO_KB(512) = 0.

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

[PATCH 1/2] arc: rename xCCM sections so they are not merged in global .data/.text

[Alexey Brodkin]

If Linux kernel is compiled with "-ffunction-sections" each function is placed 
in
its own section named ".text.function_name". This is required for
discarding of not-used functions during final linkage. But in the end
all ".text.XXX" sections are merged in the global ".text" section of
vmlinux Elf.

The same happens with data sections when "-fdata-sections" are used.

That means our ".data.arcfp" and ".text.arcfp" sections get silently
merged in global ".data" and ".text" sections even though we want to
put them in separate memory regions in case ICCM and/or DCCM exist in
the ARC core.

Solution is as simple as addition of one extra period in section name.

Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
Cc: Igor Guryanov <gurya...@synopsys.com>
Cc: sta...@vger.kernel.org
---
 arch/arc/include/asm/linkage.h | 6 +++---
 arch/arc/kernel/vmlinux.lds.S  | 8 
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arc/include/asm/linkage.h b/arch/arc/include/asm/linkage.h
index b29f1a9fd6f7..3a5f13d65ee1 100644
--- a/arch/arc/include/asm/linkage.h
+++ b/arch/arc/include/asm/linkage.h
@@ -28,7 +28,7 @@
 /* annotation for data we want in DCCM - if enabled in .config */
 .macro ARCFP_CODE
 #ifdef CONFIG_ARC_HAS_ICCM
-   .section .text.arcfp, "ax",@progbits
+   .section .text..arcfp, "ax",@progbits
 #else
.section .text, "ax",@progbits
 #endif
@@ -47,13 +47,13 @@
 #else  /* !__ASSEMBLY__ */
 
 #ifdef CONFIG_ARC_HAS_ICCM
-#define __arcfp_code __attribute__((__section__(".text.arcfp")))
+#define __arcfp_code __attribute__((__section__(".text..arcfp")))
 #else
 #define __arcfp_code __attribute__((__section__(".text")))
 #endif
 
 #ifdef CONFIG_ARC_HAS_DCCM
-#define __arcfp_data __attribute__((__section__(".data.arcfp")))
+#define __arcfp_data __attribute__((__section__(".data..arcfp")))
 #else
 #define __arcfp_data __attribute__((__section__(".data")))
 #endif
diff --git a/arch/arc/kernel/vmlinux.lds.S b/arch/arc/kernel/vmlinux.lds.S
index f35ed578e007..f69ae479ee73 100644
--- a/arch/arc/kernel/vmlinux.lds.S
+++ b/arch/arc/kernel/vmlinux.lds.S
@@ -37,8 +37,8 @@ SECTIONS
}
 
 #ifdef CONFIG_ARC_HAS_ICCM
-   .text.arcfp : {
-   *(.text.arcfp)
+   .text..arcfp : {
+   *(.text..arcfp)
. = ALIGN(CONFIG_ARC_ICCM_SZ * 1024);
}
 #endif
@@ -151,8 +151,8 @@ SECTIONS
 #ifdef CONFIG_ARC_HAS_DCCM
. = CONFIG_ARC_DCCM_BASE;
__arc_dccm_base = .;
-   .data.arcfp : {
-   *(.data.arcfp)
+   .data..arcfp : {
+   *(.data..arcfp)
}
. = ALIGN(CONFIG_ARC_DCCM_SZ * 1024);
 #endif
-- 
2.7.4


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

[PATCH 2/2] arc: Fix xCCM size check

[Alexey Brodkin]

CONFIG_ARC_ICCM_SZ in menuconfig is specified in kB while
"cpu->Xccm.sz" contains value in bytes thus direct comparison fails
leading to boot-time panic like that:
--->8-
IDENTITY: ARCVER [0x52] ARCNUM [0x1] CHIPID [ 0x0]
processor [1]   : ARC HS38 R2.1 (ARCv2 ISA)
Timers  : Timer0 Timer1 Local-64-bit-Ctr (not used)
ISA Extn: atomic ll64 unalign (not used)
: mpy[opt 9] div_rem norm barrel-shift swap minmax swape
BPU : full match, cache:2048, Predict Table:16384
MMU [v0]: 0k PAGE, JTLB 0 (0x0), uDTLB 0, uITLB 0
I-Cache : N/A
D-Cache : N/A
Peripherals : 0xf000, IO-Coherency (disabled)
Vector Table: 0x8000
FPU : SP DP
DEBUG   : ActionPoint smaRT RTT
Extn [CCM]  : DCCM @ e000, 256 KB / ICCM: @ 6000, 256 KB
OS ABI [v4] : 64-bit data any register aligned
Extn [SMP]  : ARConnect (v2): 2 cores with IPI IDU DEBUG GFRC
Kernel panic - not syncing: Linux built with incorrect DCCM Size

---[ end Kernel panic - not syncing: Linux built with incorrect DCCM Size
--->8-----

Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
Cc: Igor Guryanov <gurya...@synopsys.com>
Cc: sta...@vger.kernel.org
---
 arch/arc/kernel/setup.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arc/kernel/setup.c b/arch/arc/kernel/setup.c
index ee574f37f365..601dab6fe5e0 100644
--- a/arch/arc/kernel/setup.c
+++ b/arch/arc/kernel/setup.c
@@ -333,12 +333,12 @@ static void arc_chk_core_config(void)
if ((unsigned int)__arc_dccm_base != cpu->dccm.base_addr)
panic("Linux built with incorrect DCCM Base address\n");
 
-   if (CONFIG_ARC_DCCM_SZ != cpu->dccm.sz)
+   if (CONFIG_ARC_DCCM_SZ != TO_KB(cpu->dccm.sz))
panic("Linux built with incorrect DCCM Size\n");
 #endif
 
 #ifdef CONFIG_ARC_HAS_ICCM
-   if (CONFIG_ARC_ICCM_SZ != cpu->iccm.sz)
+   if (CONFIG_ARC_ICCM_SZ != TO_KB(cpu->iccm.sz))
panic("Linux built with incorrect ICCM Size\n");
 #endif
 
-- 
2.7.4


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

[PATCH] arc: nsim: clean-up defconfigs

[Alexey Brodkin]

Stand-alone nSIM platform has the only peripheral which is serial port.
That means support of networking and mice makes no sense for it.

Moreover removal of networking alone gives us 2 nice benefits:
 1. Build happens faster
On my machine I'm seeing this:
   Existing defconfig:
 real   2m37.887s
 user   8m22.077s
 sys0m35.995s

   New defconfig:
 real   1m35.351s
 user   5m11.988s
 sys0m25.211s

Which gives us ~60% speed-up.

 2. Memory footprint is smaller:
arc-linux-size vmlinux.org
  text data bss dec hex filename
  5829381798756  257280 6885417  691029 vmlinux.org

arc-linux-size vmlinux.new
  text data bss dec hex filename
  4426769526348  225244 5178361  4f03f9 vmlinux.new

Though this has one down-side - UNIX sockets are disabled an so on
attempt to run hackbench by default user will see:
->8---
hackbench
Running in process mode with 10 groups using 40 file descriptors each
(== 400 tasks)
Each sender will pass 100 messages of 100 bytes
Creating fdpair (error: Function not implemented)
->8---

Still it's possible to ask hackbench to use pipes instead like this:
->8---
hackbench -p
Running in process mode with 10 groups using 40 file descriptors each
(== 400 tasks)
Each sender will pass 100 messages of 100 bytes
Time: 9.216
->8---

Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
---
 arch/arc/configs/nsim_700_defconfig| 16 +---
 arch/arc/configs/nsim_hs_defconfig | 13 +
 arch/arc/configs/nsim_hs_smp_defconfig | 12 +---
 3 files changed, 3 insertions(+), 38 deletions(-)

diff --git a/arch/arc/configs/nsim_700_defconfig 
b/arch/arc/configs/nsim_700_defconfig
index b0066a749d4c..80bd8faecb95 100644
--- a/arch/arc/configs/nsim_700_defconfig
+++ b/arch/arc/configs/nsim_700_defconfig
@@ -2,7 +2,6 @@
 CONFIG_DEFAULT_HOSTNAME="ARCLinux"
 # CONFIG_SWAP is not set
 CONFIG_SYSVIPC=y
-CONFIG_POSIX_MQUEUE=y
 # CONFIG_CROSS_MEMORY_ATTACH is not set
 CONFIG_HIGH_RES_TIMERS=y
 CONFIG_IKCONFIG=y
@@ -27,22 +26,12 @@ CONFIG_ARC_PLAT_SIM=y
 CONFIG_ARC_BUILTIN_DTB_NAME="nsim_700"
 CONFIG_PREEMPT=y
 # CONFIG_COMPACTION is not set
-CONFIG_NET=y
-CONFIG_PACKET=y
-CONFIG_UNIX=y
-CONFIG_UNIX_DIAG=y
-CONFIG_NET_KEY=y
-CONFIG_INET=y
-# CONFIG_IPV6 is not set
 CONFIG_DEVTMPFS=y
 # CONFIG_STANDALONE is not set
 # CONFIG_PREVENT_FIRMWARE_BUILD is not set
 # CONFIG_FIRMWARE_IN_KERNEL is not set
 # CONFIG_BLK_DEV is not set
-CONFIG_NETDEVICES=y
-CONFIG_ARC_EMAC=y
-CONFIG_LXT_PHY=y
-# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
+# CONFIG_INPUT_MOUSEDEV is not set
 # CONFIG_INPUT_KEYBOARD is not set
 # CONFIG_INPUT_MOUSE is not set
 # CONFIG_SERIO is not set
@@ -55,11 +44,8 @@ CONFIG_SERIAL_ARC_CONSOLE=y
 # CONFIG_HID is not set
 # CONFIG_USB_SUPPORT is not set
 # CONFIG_IOMMU_SUPPORT is not set
-CONFIG_EXT2_FS=y
-CONFIG_EXT2_FS_XATTR=y
 CONFIG_TMPFS=y
 # CONFIG_MISC_FILESYSTEMS is not set
-CONFIG_NFS_FS=y
 # CONFIG_ENABLE_WARN_DEPRECATED is not set
 # CONFIG_ENABLE_MUST_CHECK is not set
 # CONFIG_DEBUG_PREEMPT is not set
diff --git a/arch/arc/configs/nsim_hs_defconfig 
b/arch/arc/configs/nsim_hs_defconfig
index ebe9ebb92933..ad8e7e53ab26 100644
--- a/arch/arc/configs/nsim_hs_defconfig
+++ b/arch/arc/configs/nsim_hs_defconfig
@@ -2,7 +2,6 @@
 CONFIG_DEFAULT_HOSTNAME="ARCLinux"
 # CONFIG_SWAP is not set
 CONFIG_SYSVIPC=y
-CONFIG_POSIX_MQUEUE=y
 # CONFIG_CROSS_MEMORY_ATTACH is not set
 CONFIG_HIGH_RES_TIMERS=y
 CONFIG_IKCONFIG=y
@@ -31,19 +30,12 @@ CONFIG_ISA_ARCV2=y
 CONFIG_ARC_BUILTIN_DTB_NAME="nsim_hs"
 CONFIG_PREEMPT=y
 # CONFIG_COMPACTION is not set
-CONFIG_NET=y
-CONFIG_PACKET=y
-CONFIG_UNIX=y
-CONFIG_UNIX_DIAG=y
-CONFIG_NET_KEY=y
-CONFIG_INET=y
-# CONFIG_IPV6 is not set
 CONFIG_DEVTMPFS=y
 # CONFIG_STANDALONE is not set
 # CONFIG_PREVENT_FIRMWARE_BUILD is not set
 # CONFIG_FIRMWARE_IN_KERNEL is not set
 # CONFIG_BLK_DEV is not set
-# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
+# CONFIG_INPUT_MOUSEDEV is not set
 # CONFIG_INPUT_KEYBOARD is not set
 # CONFIG_INPUT_MOUSE is not set
 # CONFIG_SERIO is not set
@@ -56,11 +48,8 @@ CONFIG_SERIAL_ARC_CONSOLE=y
 # CONFIG_HID is not set
 # CONFIG_USB_SUPPORT is not set
 # CONFIG_IOMMU_SUPPORT is not set
-CONFIG_EXT2_FS=y
-CONFIG_EXT2_FS_XATTR=y
 CONFIG_TMPFS=y
 # CONFIG_MISC_FILESYSTEMS is not set
-CONFIG_NFS_FS=y
 # CONFIG_ENABLE_WARN_DEPRECATED is not set
 # CONFIG_ENABLE_MUST_CHECK is not set
 # CONFIG_DEBUG_PREEMPT is not set
diff --git a/arch/arc/configs/nsim_hs_smp_defconfig 
b/arch/arc/configs/nsim_hs_smp_defconfig
index 4bde43278be6..d0e609e26bfb 100644
--- a/arch/arc/configs/nsim_hs_smp_defconfig
+++ b/arch/arc/configs/nsim_hs_smp_defconfig
@@ -30,19 +30,12 @@ CONFIG_SMP=y
 CONFIG_ARC_BUILTIN_DTB

[PATCH] arc: Allow selection of master core

[Alexey Brodkin]

We used to think that core0 is always so-called master-core
which is executed before all other cores and does some preparation
before allowing other cores to start or continue execution.

But in some cases we may want another core to be that master or we
may only run Linux on subset of cores in SMP SoC so core0 won't be
an option any longer.

That change introduces new Kconfig option that allows explicit selection
of the master core.

Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
---
 arch/arc/Kconfig   | 17 +
 arch/arc/kernel/head.S |  2 +-
 arch/arc/kernel/smp.c  |  6 +++---
 arch/arc/mm/cache.c|  4 +++-
 4 files changed, 24 insertions(+), 5 deletions(-)

diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig
index 6e89585b5ea0..c0969274874f 100644
--- a/arch/arc/Kconfig
+++ b/arch/arc/Kconfig
@@ -204,6 +204,23 @@ config ARC_SMP_HALT_ON_RESET
  at designated entry point. For other case, all jump to common
  entry point and spin wait for Master's signal.
 
+config ARC_MASTER_CORE
+   int "Master core index"
+   range 0 NR_CPUS
+   default "0"
+   help
+ Any core might be used as a master, i.e. the one which does initial
+ low-level setup before real SMP stuff is ready to be used.
+ Default 0 (the first core) is what you most probably need but if you
+ know what you are doing other cores might be used as a master.
+ This is especially useful if one wants to run Linux just on one core 
out of
+ many in SMP SoC and that core to be not the first one.
+
+ Note that value MUST BE <= (NR_CPUS - 1), i.e. if NR_CPUS=4 then 
master core
+ MUST BE in a range 0, 1, 2, 3. Unfortunately in Kconfig there's no 
way to
+ set a range with expression, so it checks for <= NR_CPUS which is not 
entirely
+ correct!
+
 endif  #SMP
 
 config ARC_MCIP
diff --git a/arch/arc/kernel/head.S b/arch/arc/kernel/head.S
index 689dd867fdff..92d203e9c57f 100644
--- a/arch/arc/kernel/head.S
+++ b/arch/arc/kernel/head.S
@@ -69,7 +69,7 @@ ENTRY(stext)
 
 #ifdef CONFIG_SMP
GET_CPU_ID  r5
-   cmp r5, 0
+   cmp r5, CONFIG_ARC_MASTER_CORE
mov.nz  r0, r5
 #ifdef CONFIG_ARC_SMP_HALT_ON_RESET
; Non-Master can proceed as system would be booted sufficiently
diff --git a/arch/arc/kernel/smp.c b/arch/arc/kernel/smp.c
index 88674d972c9d..3b1642a9c0b5 100644
--- a/arch/arc/kernel/smp.c
+++ b/arch/arc/kernel/smp.c
@@ -92,13 +92,13 @@ static volatile int wake_flag;
 
 static void arc_default_smp_cpu_kick(int cpu, unsigned long pc)
 {
-   BUG_ON(cpu == 0);
-   wake_flag = cpu;
+   BUG_ON(cpu == CONFIG_ARC_MASTER_CORE);
+   wake_flag = BIT(cpu);
 }
 
 void arc_platform_smp_wait_to_boot(int cpu)
 {
-   while (wake_flag != cpu)
+   while (wake_flag != BIT(cpu))
;
 
wake_flag = 0;
diff --git a/arch/arc/mm/cache.c b/arch/arc/mm/cache.c
index 3f443ab770e0..1260ff34 100644
--- a/arch/arc/mm/cache.c
+++ b/arch/arc/mm/cache.c
@@ -933,14 +933,16 @@ void arc_cache_init(void)
 
printk(arc_cache_mumbojumbo(0, str, sizeof(str)));
 
+#ifdef CONFIG_SMP
/*
 * Only master CPU needs to execute rest of function:
 *  - Assume SMP so all cores will have same cache config so
 *any geomtry checks will be same for all
 *  - IOC setup / dma callbacks only need to be setup once
 */
-   if (cpu)
+   if (cpu != CONFIG_ARC_MASTER_CORE)
return;
+#endif
 
if (IS_ENABLED(CONFIG_ARC_HAS_ICACHE)) {
struct cpuinfo_arc_cache *ic = _arc700[cpu].icache;
-- 
2.7.4


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

[PATCH] arc: use hardware ARCNUM in smp_processor_id()

[Alexey Brodkin]

We used to think that ARC cores in SMP SoC start
consequentially, i.e. core0 -> core1 -> core2 -> core4.

Moreover we treat core0 as a master core which does some
low-level initialization before allowing other cores to
start doing real stuff.

In that case everything works as expected - smp_processor_id()
returns expected values for all cores, i.e.:
 0 for core0
 1 for core1 etc.

But what if instead of core0 we want core1 to be the master?
That might be the case if we want to use only one core out of
SMP setup and that core is not core0 or for some other reason
modify core start-up sequence to say: core3 -> core1 > ...

In that case smp_processor_id() returns values that differ
from real hardware core index. For the first/master core that
we'l get 0, the next one will be 1 etc.

The problem here is we'll use improper cpu indexes in MCIP commands
and inevitably commands will be sent to unexpected cores causing all
sorts of unexpected behavior.

But if we use hardware core index out out IDENTITY AUX reg that problem
won't happen because cpu value will match its hardware index.

Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
Cc: sta...@vger.kernel.org
---
 arch/arc/include/asm/smp.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arc/include/asm/smp.h b/arch/arc/include/asm/smp.h
index 0861007d9ef3..5aad65d3defd 100644
--- a/arch/arc/include/asm/smp.h
+++ b/arch/arc/include/asm/smp.h
@@ -14,8 +14,9 @@
 #include 
 #include 
 #include 
+#include 
 
-#define raw_smp_processor_id() (current_thread_info()->cpu)
+#define raw_smp_processor_id() ((int)(read_aux_reg(AUX_IDENTITY) >> 8) & 0xFF)
 
 /* including cpumask.h leads to cyclic deps hence this Forward declaration */
 struct cpumask;
-- 
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 3/6] arc: Use full path in KBUILD_IMAGE definition

[Alexey Brodkin]

Hi Michal,

On Tue, 2016-11-22 at 22:34 +0100, Michal Marek wrote:
> 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

I tried to find any examples on how that KBUILD_IMAGE thingy is used
but to no avail. It looks like for ARC "bootpImage" makes not much
sense and if you really want to get something useful in .deb/.rpm
most probably something like below may work much better:
>8--
KBUILD_IMAGE:= $(boot)/uImage
>8--

And I don't know context of KBUILD_IMAGE usage but in
case of ARC our default target is "vmlinux" so I'm not sure then if
KBUILD_IMAGE may point to non-default target.

For example in "arch/avr32/Makefile" I see more complicated construction:
>8--
             KBUILD_IMAGE := $(boot)/uImage
vmlinux.elf: KBUILD_IMAGE := $(boot)/vmlinux.elf
vmlinux.cso: KBUILD_IMAGE := $(boot)/vmlinux.cso
uImage.srec: KBUILD_IMAGE := $(boot)/uImage.srec
uImage:  KBUILD_IMAGE := $(boot)/uImage
>8--
and may imagine that we need something similar for ARC obviously with
default being "$(boot)/vmlinux".

-Alexey
___
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

[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 <abrod...@synopsys.com>
---
 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 v3 0/2] DW DMAC: update device tree

[Alexey Brodkin]

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.

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.

Hope this race doesn't affect you that much.

-Alexey

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

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

[Alexey Brodkin]

Hi Daniel, David,

On Wed, 2016-11-02 at 12:23 +, Alexey Brodkin wrote:
> Hi Daniel, David,
> 
> On Mon, 2016-10-24 at 18:33 +0000, Alexey Brodkin wrote:
> > 
> > Hi Daniel,
> > 
> > > 
> > > 
> > > -Original Message-
> > > From: linux-snps-arc [mailto:linux-snps-arc-boun...@lists.infradead.org] 
> > > On Behalf Of Alexey Brodkin
> > > Sent: 19 октября 2016 г. 12:33
> > > To: dri-de...@lists.freedesktop.org; arch...@codeaurora.org; 
> > > eugeniy.palt...@synopsys.com
> > > Cc: linux-snps-arc@lists.infradead.org; linux-ker...@vger.kernel.org
> > > Subject: Re: [PATCH v2] drm/arcpgu: Accommodate adv7511 switch to DRM 
> > > bridge
> > > 
> > > Hi Archit, all,
> > > 
> > > On Wed, 2016-10-19 at 14:43 +0530, Archit Taneja wrote:
> > > > 
> > > > 
> > > > 
> > > > On 10/19/2016 01:16 PM, Eugeniy Paltsev wrote:
> > > > > 
> > > > > 
> > > > > 
> > > > > 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.
> > > 
> > > [snip]
> > > 
> > > > 
> > > > 
> > > > Looks good now.
> > > > 
> > > > Reviewed-by: Archit Taneja <arch...@codeaurora.org>
> > > 
> > > And IMHO it would be really good to get this one back-ported to 4.8
> > > because it really fixes kernel crash if ARC PGU driver is used.
> > > 
> > > It might be a bit of a problem because patch itself a little-bit larger
> > > than formal requirement for stable backports but let's see if it gets 
> > > accepted.
> > 
> > Could you please pick this one up?
> > I may alternatively send a pull-request to David but not sure if 1 patch 
> > worth it.
> > 
> > Also if that's not really too late it would be good to get this one in 4.9 
> > since the patch
> > In question fixes a real driver crash on its instantiation.
> > Actually driver crash happens since 4.8 but I failed to notice it earlier 
> > and given amount
> > of changes I think there's barely a chance for it it to be accepted in 
> > stable branches...
> > which in its turn makes at least 4.9 very desirable.
> 
> Any chance this one gets accepted anytime soon?

Please treat this as another polite reminder to apply this patch.
If you prefer I may send a pull-request otherwise.

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

Re: Errors building kernel 4.9-rc4

[Alexey Brodkin]

Hi Vineet,

On Tue, 2016-11-08 at 08:54 -0800, Vineet Gupta wrote:
> On 11/08/2016 02:51 AM, Luis Oliveira wrote:
> > 
> > Hi all,
> > 
> > Below is a list of errors while compiling a clean image of kernel 4.9-rc4.
> > 
> > Regards,
> > Luis
> 
> The issue is due to commit c3005475889c "ARC: build: retire old toggles" which
> removed supposedly obsolete toggles just to make way for removing them from 
> the
> tools. However it seems they are no so obsolete as I thought they were.
> 
> I'm going to have that reverted for now and maybe do this next year when 
> tools are
> immune to this change.
> 
> @Alexey, I tried 2016.03 and that seems to build fine with that patch - what
> version of gcc is Luis using in this buildroot ?

Saying 2016.03 are you referring to arc-2016.03 tools?

I see Luis uses "buildroot-arc-2016.02-rc2" supposedly from this tag:
https://github.com/foss-for-synopsys-dwc-arc-processors/buildroot/tree/arc-2016.02-rc2

And in that tag arc-2015.12 tools are used.

-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: [plat-eznps] set default baud for early console

[Alexey Brodkin]

Hi Noam,

On Tue, 2016-11-08 at 15:20 +0200, Noam Camus wrote:
> From: Noam Camus 
> 
> For CONFIG_SERIAL_EARLYCON we need 800MHz for NPS SoC
> The early console driver uses BASE_BAUD and not using dtb.
> 
> The default of 50MHz is NOT good for NPS SoC.
> 
> Signed-off-by: Noam Camus 

Could you please provide a changelog (v1 -> v2) so reviewers
may have a hint about changes you made if any.

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

RE: [PATCH v2 01/10] ARC: timer: rtc: implement read loop in "C" vs. inline asm

[Alexey Brodkin]

Hi Vineet,

> -Original Message-
> From: Vineet Gupta [mailto:vgu...@synopsys.com]
> Sent: Friday, November 04, 2016 12:32 AM
> To: Daniel Lezcano 
> Cc: Noam Camus ; t...@linutronix.de; 
> linux-snps-arc@lists.infradead.org; linux-ker...@vger.kernel.org;
> alexey.brod...@synopsys.com; Vineet Gupta ; 
> sta...@vger.kernel.org
> Subject: [PATCH v2 01/10] ARC: timer: rtc: implement read loop in "C" vs. 
> inline asm
> 
> The current code doesn't even compile 
> 
> CC: sta...@vger.kernel.org
> Signed-off-by: Vineet Gupta 
> ---
>  arch/arc/kernel/time.c | 19 +++
>  1 file changed, 11 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arc/kernel/time.c b/arch/arc/kernel/time.c
> index f927b8dc6edd..1a117b999c0c 100644
> --- a/arch/arc/kernel/time.c
> +++ b/arch/arc/kernel/time.c
> @@ -152,14 +152,17 @@ static cycle_t arc_read_rtc(struct clocksource *cs)
>   cycle_t  full;
>   } stamp;
> 
> -
> - __asm__ __volatile(
> - "1: \n"
> - "   lr  %0, [AUX_RTC_LOW]   \n"
> - "   lr  %1, [AUX_RTC_HIGH]  \n"
> - "   lr  %2, [AUX_RTC_CTRL]  \n"
> - "   bbit0.nt%2, 31, 1b  \n"
> - : "=r" (stamp.low), "=r" (stamp.high), "=r" (status));
> +/*
> + * hardware has an internal state machine which tracks readout of
> + * low/high and updates the CTRL.status if
> + *  - interrupt/exception taken between the two reads
> + *  - high increments after low has been read
> + */
> + do {
> + stamp.low = read_aux_reg(AUX_RTC_LOW);
> + stamp.high = read_aux_reg(AUX_RTC_HIGH);
> + status = read_aux_reg(AUX_RTC_CTRL);
> + } while (!(status & _BITUL(31)));

I think original Daniel's comment was about constant value used here.
Now with "_BITUL" it already looks much better but IMHO it would be even better 
if
31 gets converted here to something like:
>8
#define RTC_CTRL_A1_OFFSET 31
>8

-Alexey

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

stmmac: GMAC_RGSMIIIS reports bogus values

[Alexey Brodkin]

Hello,

I'm seeing pretty strange issue with GMAC reporting a lot of link state changes
based on bits in GMAC_RGSMIIIS. It looks like that:
-->8---
Link is Down
Link is Up - 10/Full
Link is Down
Link is Up - 10/Half
Link is Down
Link is Down
Link is Up - 10/Half
Link is Up -
1000/Half
Link is Down
Link is Down
Link is Down
Link is Down
Link is Up - 10/Half
Link is Down
Link is Down
Link is Up -
1000/Half
Link is Up - 1000/Full
-->8---

What's especially interesting my board with GMAC is connected to 100Mbit device
which means there's no chance for 1Gb mode to be set.

Also this has nothing to do with link state detected and reported by PHY via 
MDIO.
So obviously GMAC_RGSMIIIS bits are wrong. But given the fact that 
GMAC_RGSMIIIS bits
are set based on state of RXD[3:0] lines of RGMII I may only thing that it's
PHY (in my case DP83865) who's sending random data on the RXD during 
inter-frame gap.

Note data transferred through that networking connection is perfectly correct 
and
actually I haven't see those link state prints before kernel v4.8 basically
because the prints in question were implemented with pr_debug() and then with 
[1]
we got pr_info() that made prints visible by default.

Since I don't have any means to capture all required GMII signals to do better
analysis and my data is not corrupted in the end I'm thinking about way how to
mute these pretty senseless messages.

One thing I may think of we may disable checking of GMAC_RGSMIIIS if a 
particular
board uses MDIO for PHY setup. Something like that:
-->8---
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c
@@ -337,7 +337,7 @@ static int dwmac1000_irq_status(struct mac_device_info *hw,
 
dwmac_pcs_isr(ioaddr, GMAC_PCS_BASE, intr_status, x);
 
-   if (intr_status & PCS_RGSMIIIS_IRQ)
+   if (!priv->use_mdio && (intr_status & PCS_RGSMIIIS_IRQ))
dwmac1000_rgsmii(ioaddr, x);
 
return ret;
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 6c85b61aaa0b..34e9de0450ba 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -3356,11 +3356,13 @@ int stmmac_dvr_probe(struct device *device,
 
stmmac_check_pcs_mode(priv);
 
+   priv->use_mdio = 0;
if (priv->hw->pcs != STMMAC_PCS_RGMII  &&
priv->hw->pcs != STMMAC_PCS_TBI &&
priv->hw->pcs != STMMAC_PCS_RTBI) {
/* MDIO bus Registration */
ret = stmmac_mdio_register(ndev);
+   priv->use_mdio = 1;
if (ret < 0) {
pr_debug("%s: MDIO bus (id: %d) registration failed",
 __func__, priv->plat->bus_id);
-->8---

Any thoughts on that are much appreciated!

Regards,
Alexey

[1] 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=70523e639bf8ca09b3357371c3546cee55c06351
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

[PATCH v2] arc: Implement arch-specific dma_map_ops.mmap

[Alexey Brodkin]

We used to use generic implementation of dma_map_ops.mmap which is
dma_common_mmap() but that only worked for simpler cached mappings when
vaddr = paddr.

If a driver requests uncached DMA buffer kernel maps it to virtual
address so that MMU gets involved and page uncached status takes into
account. In that case usage of dma_common_mmap() lead to mapping of
vaddr to vaddr for user-space which is obviously wrong. For more detals
please refer to verbose explanation here [1].

So here we implement our own version of mmap() which always deals
with dma_addr and maps underlying memory to user-space properly
(note that DMA buffer mapped to user-space is always uncached
because there's no way to properly manage cache from user-space).

[1] https://lkml.org/lkml/2016/10/26/973

Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
Reviewed-by: Catalin Marinas <catalin.mari...@arm.com>
Cc: Marek Szyprowski <m.szyprow...@samsung.com>
Cc: Vineet Gupta <vgu...@synopsys.com>
Cc: <sta...@vger.kernel.org>
---

Changes v1 -> v2:
 * Added plat_dma_to_phys wrapper around dma_addr

 arch/arc/mm/dma.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/arc/mm/dma.c b/arch/arc/mm/dma.c
index 20afc65e22dc..9288851d43a0 100644
--- a/arch/arc/mm/dma.c
+++ b/arch/arc/mm/dma.c
@@ -105,6 +105,31 @@ static void arc_dma_free(struct device *dev, size_t size, 
void *vaddr,
__free_pages(page, get_order(size));
 }
 
+static int arc_dma_mmap(struct device *dev, struct vm_area_struct *vma,
+   void *cpu_addr, dma_addr_t dma_addr, size_t size,
+   unsigned long attrs)
+{
+   unsigned long user_count = vma_pages(vma);
+   unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT;
+   unsigned long pfn = __phys_to_pfn(plat_dma_to_phys(dev, dma_addr));
+   unsigned long off = vma->vm_pgoff;
+   int ret = -ENXIO;
+
+   vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
+
+   if (dma_mmap_from_coherent(dev, vma, cpu_addr, size, ))
+   return ret;
+
+   if (off < count && user_count <= (count - off)) {
+   ret = remap_pfn_range(vma, vma->vm_start,
+ pfn + off,
+ user_count << PAGE_SHIFT,
+ vma->vm_page_prot);
+   }
+
+   return ret;
+}
+
 /*
  * streaming DMA Mapping API...
  * CPU accesses page via normal paddr, thus needs to explicitly made
@@ -193,6 +218,7 @@ static int arc_dma_supported(struct device *dev, u64 
dma_mask)
 struct dma_map_ops arc_dma_ops = {
.alloc  = arc_dma_alloc,
.free   = arc_dma_free,
+   .mmap   = arc_dma_mmap,
.map_page   = arc_dma_map_page,
.map_sg = arc_dma_map_sg,
.sync_single_for_device = arc_dma_sync_single_for_device,
-- 
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 v2] drm/arcpgu: Accommodate adv7511 switch to DRM bridge

[Alexey Brodkin]

Hi Daniel, David,

On Mon, 2016-10-24 at 18:33 +, Alexey Brodkin wrote:
> Hi Daniel,
> 
> > 
> > -Original Message-
> > From: linux-snps-arc [mailto:linux-snps-arc-boun...@lists.infradead.org] On 
> > Behalf Of Alexey Brodkin
> > Sent: 19 октября 2016 г. 12:33
> > To: dri-de...@lists.freedesktop.org; arch...@codeaurora.org; 
> > eugeniy.palt...@synopsys.com
> > Cc: linux-snps-arc@lists.infradead.org; linux-ker...@vger.kernel.org
> > Subject: Re: [PATCH v2] drm/arcpgu: Accommodate adv7511 switch to DRM bridge
> > 
> > Hi Archit, all,
> > 
> > On Wed, 2016-10-19 at 14:43 +0530, Archit Taneja wrote:
> > > 
> > > 
> > > On 10/19/2016 01:16 PM, Eugeniy Paltsev wrote:
> > > > 
> > > > 
> > > > 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.
> > 
> > [snip]
> > 
> > > 
> > > Looks good now.
> > > 
> > > Reviewed-by: Archit Taneja <arch...@codeaurora.org>
> > 
> > And IMHO it would be really good to get this one back-ported to 4.8
> > because it really fixes kernel crash if ARC PGU driver is used.
> > 
> > It might be a bit of a problem because patch itself a little-bit larger
> > than formal requirement for stable backports but let's see if it gets 
> > accepted.
> 
> Could you please pick this one up?
> I may alternatively send a pull-request to David but not sure if 1 patch 
> worth it.
> 
> Also if that's not really too late it would be good to get this one in 4.9 
> since the patch
> In question fixes a real driver crash on its instantiation.
> Actually driver crash happens since 4.8 but I failed to notice it earlier and 
> given amount
> of changes I think there's barely a chance for it it to be accepted in stable 
> branches...
> which in its turn makes at least 4.9 very desirable.

Any chance this one gets accepted anytime soon?

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

[PATCH] arc: Implement arch-specific dma_map_ops.mmap

[Alexey Brodkin]

We used to use generic implementation of dma_map_ops.mmap which is
dma_common_mmap() but that only worked for simpler cached mappings when
vaddr = paddr.

If a driver requests uncached DMA buffer kernel maps it to virtual
address so that MMU gets involved and page uncached status takes into
account. In that case usage of dma_common_mmap() lead to mapping of
vaddr to vaddr for user-space which is obviously wrong. For more detals
please refer to verbose explanation here [1].

So here we implement our own version of mmap() which always deals
with dma_addr and maps underlying memory to user-space properly
(note that DMA buffer mapped to user-space is always uncached
because there's no way to properly manage cache from user-space).

[1] https://lkml.org/lkml/2016/10/26/973

Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
Cc: Catalin Marinas <catalin.mari...@arm.com>
Cc: Marek Szyprowski <m.szyprow...@samsung.com>
Cc: sta...@vger.kernel.org
---
 arch/arc/mm/dma.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/arch/arc/mm/dma.c b/arch/arc/mm/dma.c
index 20afc65e22dc..034ec6a8a764 100644
--- a/arch/arc/mm/dma.c
+++ b/arch/arc/mm/dma.c
@@ -105,6 +105,31 @@ static void arc_dma_free(struct device *dev, size_t size, 
void *vaddr,
__free_pages(page, get_order(size));
 }
 
+static int arc_dma_mmap(struct device *dev, struct vm_area_struct *vma,
+   void *cpu_addr, dma_addr_t dma_addr, size_t size,
+   unsigned long attrs)
+{
+   unsigned long user_count = vma_pages(vma);
+   unsigned long count = PAGE_ALIGN(size) >> PAGE_SHIFT;
+   unsigned long pfn = __phys_to_pfn(dma_addr);
+   unsigned long off = vma->vm_pgoff;
+   int ret = -ENXIO;
+
+   vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
+
+   if (dma_mmap_from_coherent(dev, vma, cpu_addr, size, ))
+   return ret;
+
+   if (off < count && user_count <= (count - off)) {
+   ret = remap_pfn_range(vma, vma->vm_start,
+ pfn + off,
+ user_count << PAGE_SHIFT,
+ vma->vm_page_prot);
+   }
+
+   return ret;
+}
+
 /*
  * streaming DMA Mapping API...
  * CPU accesses page via normal paddr, thus needs to explicitly made
@@ -193,6 +218,7 @@ static int arc_dma_supported(struct device *dev, u64 
dma_mask)
 struct dma_map_ops arc_dma_ops = {
.alloc  = arc_dma_alloc,
.free   = arc_dma_free,
+   .mmap   = arc_dma_mmap,
.map_page   = arc_dma_map_page,
.map_sg = arc_dma_map_sg,
.sync_single_for_device = arc_dma_sync_single_for_device,
-- 
2.7.4


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

[PATCH v2] ARC: Enable PERF_EVENTS in nSIM driven platforms

[Alexey Brodkin]

Now when we have properly working performance counters in nSIM
even with interrupt support (fix should be a part of upcoming
nSIM engineering build 2016.12-005) we may enable perf support
by default for all platforms that use nSIM for ARC cores simulation.

Note 1: PCT node was missing for some reason in nsimosci.dts
while all other nSIM-related .dts files already had
PCT node for quite some time, so adding it now.

Note 2: All defconfigs were regenerated with "make savedefconfig"
which led to some clean-ups in nsimosci_hs_smp_defconfig:
CONFIG_FRAMEBUFFER_CONSOLE=y was removed because it is
automatically selected now by DRM.

Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
---

changes v1 -> v2:
 * Added missing PCT Device Tree node in nsimosci.dts

 arch/arc/boot/dts/nsimosci.dts | 4 
 arch/arc/configs/nsim_700_defconfig| 1 +
 arch/arc/configs/nsim_hs_defconfig | 1 +
 arch/arc/configs/nsim_hs_smp_defconfig | 1 +
 arch/arc/configs/nsimosci_defconfig| 1 +
 arch/arc/configs/nsimosci_hs_defconfig | 1 +
 arch/arc/configs/nsimosci_hs_smp_defconfig | 3 +--
 7 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/arc/boot/dts/nsimosci.dts b/arch/arc/boot/dts/nsimosci.dts
index bcf603142a33..7fe184435956 100644
--- a/arch/arc/boot/dts/nsimosci.dts
+++ b/arch/arc/boot/dts/nsimosci.dts
@@ -83,5 +83,9 @@
reg = <0xf0003000 0x44>;
interrupts = <7>;
};
+
+   arcpct0: pct {
+   compatible = "snps,archs-pct";
+   };
};
 };
diff --git a/arch/arc/configs/nsim_700_defconfig 
b/arch/arc/configs/nsim_700_defconfig
index 7314f538847b..b0066a749d4c 100644
--- a/arch/arc/configs/nsim_700_defconfig
+++ b/arch/arc/configs/nsim_700_defconfig
@@ -14,6 +14,7 @@ CONFIG_BLK_DEV_INITRD=y
 CONFIG_INITRAMFS_SOURCE="../arc_initramfs/"
 CONFIG_KALLSYMS_ALL=y
 CONFIG_EMBEDDED=y
+CONFIG_PERF_EVENTS=y
 # CONFIG_SLUB_DEBUG is not set
 # CONFIG_COMPAT_BRK is not set
 CONFIG_KPROBES=y
diff --git a/arch/arc/configs/nsim_hs_defconfig 
b/arch/arc/configs/nsim_hs_defconfig
index 65ab9fbf83f2..ebe9ebb92933 100644
--- a/arch/arc/configs/nsim_hs_defconfig
+++ b/arch/arc/configs/nsim_hs_defconfig
@@ -14,6 +14,7 @@ CONFIG_BLK_DEV_INITRD=y
 CONFIG_INITRAMFS_SOURCE="../../arc_initramfs_hs/"
 CONFIG_KALLSYMS_ALL=y
 CONFIG_EMBEDDED=y
+CONFIG_PERF_EVENTS=y
 # CONFIG_SLUB_DEBUG is not set
 # CONFIG_COMPAT_BRK is not set
 CONFIG_KPROBES=y
diff --git a/arch/arc/configs/nsim_hs_smp_defconfig 
b/arch/arc/configs/nsim_hs_smp_defconfig
index 3b3990cddbe1..4bde43278be6 100644
--- a/arch/arc/configs/nsim_hs_smp_defconfig
+++ b/arch/arc/configs/nsim_hs_smp_defconfig
@@ -12,6 +12,7 @@ CONFIG_BLK_DEV_INITRD=y
 CONFIG_INITRAMFS_SOURCE="../arc_initramfs_hs/"
 CONFIG_KALLSYMS_ALL=y
 CONFIG_EMBEDDED=y
+CONFIG_PERF_EVENTS=y
 # CONFIG_SLUB_DEBUG is not set
 # CONFIG_COMPAT_BRK is not set
 CONFIG_KPROBES=y
diff --git a/arch/arc/configs/nsimosci_defconfig 
b/arch/arc/configs/nsimosci_defconfig
index 98cf20933bbb..f6fb3d26557e 100644
--- a/arch/arc/configs/nsimosci_defconfig
+++ b/arch/arc/configs/nsimosci_defconfig
@@ -14,6 +14,7 @@ CONFIG_BLK_DEV_INITRD=y
 CONFIG_INITRAMFS_SOURCE="../arc_initramfs/"
 CONFIG_KALLSYMS_ALL=y
 CONFIG_EMBEDDED=y
+CONFIG_PERF_EVENTS=y
 # CONFIG_SLUB_DEBUG is not set
 # CONFIG_COMPAT_BRK is not set
 CONFIG_KPROBES=y
diff --git a/arch/arc/configs/nsimosci_hs_defconfig 
b/arch/arc/configs/nsimosci_hs_defconfig
index ddf8b96d494e..b9f0fe00044b 100644
--- a/arch/arc/configs/nsimosci_hs_defconfig
+++ b/arch/arc/configs/nsimosci_hs_defconfig
@@ -14,6 +14,7 @@ CONFIG_BLK_DEV_INITRD=y
 CONFIG_INITRAMFS_SOURCE="../arc_initramfs_hs/"
 CONFIG_KALLSYMS_ALL=y
 CONFIG_EMBEDDED=y
+CONFIG_PERF_EVENTS=y
 # CONFIG_SLUB_DEBUG is not set
 # CONFIG_COMPAT_BRK is not set
 CONFIG_KPROBES=y
diff --git a/arch/arc/configs/nsimosci_hs_smp_defconfig 
b/arch/arc/configs/nsimosci_hs_smp_defconfig
index ceb90745326e..6da71ba253a9 100644
--- a/arch/arc/configs/nsimosci_hs_smp_defconfig
+++ b/arch/arc/configs/nsimosci_hs_smp_defconfig
@@ -10,6 +10,7 @@ CONFIG_IKCONFIG_PROC=y
 # CONFIG_PID_NS is not set
 CONFIG_BLK_DEV_INITRD=y
 CONFIG_INITRAMFS_SOURCE="../arc_initramfs_hs/"
+CONFIG_PERF_EVENTS=y
 # CONFIG_COMPAT_BRK is not set
 CONFIG_KPROBES=y
 CONFIG_MODULES=y
@@ -34,7 +35,6 @@ CONFIG_INET=y
 # CONFIG_INET_XFRM_MODE_TRANSPORT is not set
 # CONFIG_INET_XFRM_MODE_TUNNEL is not set
 # CONFIG_INET_XFRM_MODE_BEET is not set
-# CONFIG_INET_LRO is not set
 # CONFIG_IPV6 is not set
 # CONFIG_WIRELESS is not set
 CONFIG_DEVTMPFS=y
@@ -72,7 +72,6 @@ CONFIG_SERIAL_OF_PLATFORM=y
 # CONFIG_HWMON is not set
 CONFIG_DRM=y
 CONFIG_DRM_ARCPGU=y
-CONFIG_FRAMEBUFFER_CONSOLE=y
 CONFIG_LOGO=y
 # CONFIG_HID is not set
 # CONFIG_USB_SUPPORT is not set
-- 
2.7.4


__

[PATCH] ARC: Enable PERF_EVENTS in nSIM driven platforms

[Alexey Brodkin]

Now when we have properly working performance counters in nSIM
even with interrupt support (fix should be a part of upcoming
nSIM engineering build 2016.12-005) we may enable perf support
by default for all platforms that use nSIM for ARC cores simulation.

Note all defconfigs were regenerated with "make savedefconfig"
which led to some clean-ups in nsimosci_hs_smp_defconfig:
CONFIG_FRAMEBUFFER_CONSOLE=y was removed because it is automatically
selected now by DRM.

Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
---
 arch/arc/configs/nsim_700_defconfig| 1 +
 arch/arc/configs/nsim_hs_defconfig | 1 +
 arch/arc/configs/nsim_hs_smp_defconfig | 1 +
 arch/arc/configs/nsimosci_defconfig| 1 +
 arch/arc/configs/nsimosci_hs_defconfig | 1 +
 arch/arc/configs/nsimosci_hs_smp_defconfig | 3 +--
 6 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arc/configs/nsim_700_defconfig 
b/arch/arc/configs/nsim_700_defconfig
index 7314f538847b..b0066a749d4c 100644
--- a/arch/arc/configs/nsim_700_defconfig
+++ b/arch/arc/configs/nsim_700_defconfig
@@ -14,6 +14,7 @@ CONFIG_BLK_DEV_INITRD=y
 CONFIG_INITRAMFS_SOURCE="../arc_initramfs/"
 CONFIG_KALLSYMS_ALL=y
 CONFIG_EMBEDDED=y
+CONFIG_PERF_EVENTS=y
 # CONFIG_SLUB_DEBUG is not set
 # CONFIG_COMPAT_BRK is not set
 CONFIG_KPROBES=y
diff --git a/arch/arc/configs/nsim_hs_defconfig 
b/arch/arc/configs/nsim_hs_defconfig
index 65ab9fbf83f2..ebe9ebb92933 100644
--- a/arch/arc/configs/nsim_hs_defconfig
+++ b/arch/arc/configs/nsim_hs_defconfig
@@ -14,6 +14,7 @@ CONFIG_BLK_DEV_INITRD=y
 CONFIG_INITRAMFS_SOURCE="../../arc_initramfs_hs/"
 CONFIG_KALLSYMS_ALL=y
 CONFIG_EMBEDDED=y
+CONFIG_PERF_EVENTS=y
 # CONFIG_SLUB_DEBUG is not set
 # CONFIG_COMPAT_BRK is not set
 CONFIG_KPROBES=y
diff --git a/arch/arc/configs/nsim_hs_smp_defconfig 
b/arch/arc/configs/nsim_hs_smp_defconfig
index 3b3990cddbe1..4bde43278be6 100644
--- a/arch/arc/configs/nsim_hs_smp_defconfig
+++ b/arch/arc/configs/nsim_hs_smp_defconfig
@@ -12,6 +12,7 @@ CONFIG_BLK_DEV_INITRD=y
 CONFIG_INITRAMFS_SOURCE="../arc_initramfs_hs/"
 CONFIG_KALLSYMS_ALL=y
 CONFIG_EMBEDDED=y
+CONFIG_PERF_EVENTS=y
 # CONFIG_SLUB_DEBUG is not set
 # CONFIG_COMPAT_BRK is not set
 CONFIG_KPROBES=y
diff --git a/arch/arc/configs/nsimosci_defconfig 
b/arch/arc/configs/nsimosci_defconfig
index 98cf20933bbb..f6fb3d26557e 100644
--- a/arch/arc/configs/nsimosci_defconfig
+++ b/arch/arc/configs/nsimosci_defconfig
@@ -14,6 +14,7 @@ CONFIG_BLK_DEV_INITRD=y
 CONFIG_INITRAMFS_SOURCE="../arc_initramfs/"
 CONFIG_KALLSYMS_ALL=y
 CONFIG_EMBEDDED=y
+CONFIG_PERF_EVENTS=y
 # CONFIG_SLUB_DEBUG is not set
 # CONFIG_COMPAT_BRK is not set
 CONFIG_KPROBES=y
diff --git a/arch/arc/configs/nsimosci_hs_defconfig 
b/arch/arc/configs/nsimosci_hs_defconfig
index ddf8b96d494e..b9f0fe00044b 100644
--- a/arch/arc/configs/nsimosci_hs_defconfig
+++ b/arch/arc/configs/nsimosci_hs_defconfig
@@ -14,6 +14,7 @@ CONFIG_BLK_DEV_INITRD=y
 CONFIG_INITRAMFS_SOURCE="../arc_initramfs_hs/"
 CONFIG_KALLSYMS_ALL=y
 CONFIG_EMBEDDED=y
+CONFIG_PERF_EVENTS=y
 # CONFIG_SLUB_DEBUG is not set
 # CONFIG_COMPAT_BRK is not set
 CONFIG_KPROBES=y
diff --git a/arch/arc/configs/nsimosci_hs_smp_defconfig 
b/arch/arc/configs/nsimosci_hs_smp_defconfig
index ceb90745326e..6da71ba253a9 100644
--- a/arch/arc/configs/nsimosci_hs_smp_defconfig
+++ b/arch/arc/configs/nsimosci_hs_smp_defconfig
@@ -10,6 +10,7 @@ CONFIG_IKCONFIG_PROC=y
 # CONFIG_PID_NS is not set
 CONFIG_BLK_DEV_INITRD=y
 CONFIG_INITRAMFS_SOURCE="../arc_initramfs_hs/"
+CONFIG_PERF_EVENTS=y
 # CONFIG_COMPAT_BRK is not set
 CONFIG_KPROBES=y
 CONFIG_MODULES=y
@@ -34,7 +35,6 @@ CONFIG_INET=y
 # CONFIG_INET_XFRM_MODE_TRANSPORT is not set
 # CONFIG_INET_XFRM_MODE_TUNNEL is not set
 # CONFIG_INET_XFRM_MODE_BEET is not set
-# CONFIG_INET_LRO is not set
 # CONFIG_IPV6 is not set
 # CONFIG_WIRELESS is not set
 CONFIG_DEVTMPFS=y
@@ -72,7 +72,6 @@ CONFIG_SERIAL_OF_PLATFORM=y
 # CONFIG_HWMON is not set
 CONFIG_DRM=y
 CONFIG_DRM_ARCPGU=y
-CONFIG_FRAMEBUFFER_CONSOLE=y
 CONFIG_LOGO=y
 # CONFIG_HID is not set
 # CONFIG_USB_SUPPORT 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: Build regressions/improvements in v4.9-rc1

[Alexey Brodkin]

Hi Thomas, Michael,

On Thu, 2016-10-27 at 09:07 +0200, Thomas Petazzoni wrote:
> Hello,
> 
> On Thu, 27 Oct 2016 10:56:02 +1100, Michael Ellerman wrote:
> 
> > 
> > > 
> > > 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
> > >   
> > 
> > Thanks, I grabbed that and it works for axs103_smp_defconfig:
> > 
> >   http://kisskb.ellerman.id.au/kisskb/buildresult/12840656/
> > 
> > 
> > It doesn't work for axs101_defconfig, saying:
> > 
> >   arch/arc/Makefile:29: *** Toolchain not configured for ARCompact builds.  
> > Stop.
> 
> axs101 is using a 770 core, while the toolchain is built for the HS38
> core. I'm somewhat surprised that a single ARC toolchain cannot produce
> code for both 770 and HS38, but it seems to be the case.
> 
> So you need a separate toolchain for ARC770.

Indeed axs101 uses ARC770 core which is ARCv1 AKA ARCompact ISA while
axs103 sports the same base-board but CPU daughter-card contains ARC HS38 core
which has ARCv2 ISA (binary incompatible with ARCompact).

Essentially both gcc and binutils will happily build for both architectures 
given
proper options were passed on the command line. But Linux kernel gets linked 
with
pre-built libgcc (it is a part of toolchain). And so it all boils down to a 
requirement
to have multilibbed uClibc toolchain. Which we don't have.

I think we discussed it a couple of times already and probably at some point 
will have it
but for now we have to use 2 different toolchains for ARCompact and ARCv2 cores.

I hope explanation above makes some sense.

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

[RFC] dma-mapping: fix dma_common_mmap() for ARC

[Alexey Brodkin]

ARC CPU with enabled MMU sees entire 32-bit address space divided in 2
big parts:
 1) 0 - 0x7fff_ (lower 2Gb): translated memory
I.e. all reads/writes from/to this region go through MMU and after
translation land somewhere in physical memory.

 2) 0x8000_ - 0x_: untranslated memory
ARC CPU in kernel mode accesses this memory directly, i.e. MMU is
not used at all.
One important note: data accesses in this region go through data
cache!

If some peripheral wants to use DMA Linux kernel just allocates data
buffer in upper 2Gb (i.e. above 0x8000_).
In that case dma_addr = cpu_addr. Everything is simple.

But if a driver wants to allocate uncached buffer for DMA (very good
example and that's how I actually caught the issue is DRM frame-buffer)
things become a little-bit more complicated.

Now kernel wants to write data in memory bypassing data cache.
For that to happen we have to program MMU so that TLB entry gets
"cached flag" reset for a particular page(s). And keeping in mind
explanation above the only way to utilize MMU is to access data via
lower part of address space. In other words we implement page mapping
similarly to what we do for user-space, see:
>8---
arc_dma_alloc()
  ioremap_nocache() AKA ioremap()
ioremap_prot()
  get_vm_area() + ioremap_page_range() on obtained vaddr
>8---

As a result we get TLB entry of the following kind:
>8---
vaddr = 0x7200_
paddr = 0x8200_
flags = _uncached_
>8---

Kerenl thinks frame buffer is located @ 0x7200_ and uses it
perfectly fine.

But here comes a time for user-space application to request frame buffer
to be mapped for it. That happens easily with the following call path:
>8---
fb_mmap()
  drm_fb_cma_mmap()
dma_mmap_writecombine() AKA dma_mmap_wc()
  dma_mmap_attrs()
dma_common_mmap() since we don't [yet] have dma_map_ops.mmap()
  for ARC
>8---

And in dma_common_mmap() we first calculate pfn of what we think is
"physical page" and then do remap_pfn_range() to that "physical page".

Here we're getting to the interesting thing - how pfn is calculated.
As of now this is done as simple as:
>8---
pfn = page_to_pfn(virt_to_page(cpu_addr));
>8---

Below is a nice set of defines we need to use to evaluate pfn:
>8---
 #define virt_to_pfn(kaddr)  (__pa(kaddr) >> PAGE_SHIFT)
 #define virt_to_page(kaddr) pfn_to_page(virt_to_pfn(kaddr))
 #define page_to_pfn __page_to_pfn
 #define pfn_to_page __pfn_to_page
 #define __pfn_to_page(pfn)  (mem_map + ((pfn) - ARCH_PFN_OFFSET))
 #define __page_to_pfn(page) ((unsigned long)((page) - mem_map) + \
   ARCH_PFN_OFFSET)
>8---

If we do some obvious calculations we'll get:
>8---
pfn = cpu_addr >> PAGE_SHIFT;
>8---

In our case cpu_addr here is 0x7200_ from TLB entry above and this
what is used to create another TLB entry this time for user-space app.
We'll get something like this:
>8---
vaddr = 0x0200_
paddr = 0x7200_
flags = _uncached_
>8---

This is obviously wrong! We cannot map vaddr to vaddr with MMU.

Simplest fix for ARC is to use dma_addr instead because it matches
real physical memory address and so mapping for user-space we're
getting then is this:
>8---
vaddr = 0x0200_
paddr = 0x8200_
flags = _uncached_
>8---
And it works perfectly fine.

But I'm pretty sure that's not the best approach for other
architectures. Indeed we may create ARC-specific dma_map_ops.mmap()
which only differs from dma_common_mmap() with addr being used
but IMHO it's not the best idea to duplicate that much of code
for such a simple change.

Would be interesting to get more opinions on how to handle that thing in
the most graceful way.

Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
Cc: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Cc: Marek Szyprowski <m.szyprow...@samsung.com>
Cc: linux-snps-arc@lists.infradead.org
Cc: linux-a...@vger.kernel.org
---
 drivers/base/dma-mapping.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index 8f8b68c80986..16307eed453f 1006

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

[Alexey Brodkin]

Hi Daniel,

> -Original Message-
> From: linux-snps-arc [mailto:linux-snps-arc-boun...@lists.infradead.org] On 
> Behalf Of Alexey Brodkin
> Sent: 19 октября 2016 г. 12:33
> To: dri-de...@lists.freedesktop.org; arch...@codeaurora.org; 
> eugeniy.palt...@synopsys.com
> Cc: linux-snps-arc@lists.infradead.org; linux-ker...@vger.kernel.org
> Subject: Re: [PATCH v2] drm/arcpgu: Accommodate adv7511 switch to DRM bridge
> 
> Hi Archit, all,
> 
> On Wed, 2016-10-19 at 14:43 +0530, Archit Taneja wrote:
> >
> > On 10/19/2016 01:16 PM, Eugeniy Paltsev wrote:
> > >
> > > 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.
> 
> [snip]
> 
> > Looks good now.
> >
> > Reviewed-by: Archit Taneja <arch...@codeaurora.org>
> 
> And IMHO it would be really good to get this one back-ported to 4.8
> because it really fixes kernel crash if ARC PGU driver is used.
> 
> It might be a bit of a problem because patch itself a little-bit larger
> than formal requirement for stable backports but let's see if it gets 
> accepted.

Could you please pick this one up?
I may alternatively send a pull-request to David but not sure if 1 patch worth 
it.

Also if that's not really too late it would be good to get this one in 4.9 
since the patch
In question fixes a real driver crash on its instantiation.
Actually driver crash happens since 4.8 but I failed to notice it earlier and 
given amount
of changes I think there's barely a chance for it it to be accepted in stable 
branches...
which in its turn makes at least 4.9 very desirable.

-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

[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: [PATCH] ARCv2: intc: untangle SMP, MCIP and IDU

[Alexey Brodkin]

Hi Vineet,

On Thu, 2016-10-06 at 10:10 -0700, Vineet Gupta wrote:
> On 10/06/2016 02:10 AM, Alexey Brodkin wrote:
> > 
> > > 
> > > +struct mcip_bcr {
> > > +#ifdef CONFIG_CPU_BIG_ENDIAN
> > > + unsigned int pad3:8,
> > > +  idu:1, llm:1, num_cores:6,
> > > +  iocoh:1,  gfrc:1, dbg:1, pad2:1,
> > > +  msg:1, sem:1, ipi:1, pad:1,
> > > +  ver:8;
> > > +#else
> > > + unsigned int ver:8,
> > > +  pad:1, ipi:1, sem:1, msg:1,
> > > +  pad2:1, dbg:1, gfrc:1, iocoh:1,
> > > +  num_cores:6, llm:1, idu:1,
> > > +  pad3:8;
> > > +#endif
> > > +};
> > 
> > IMHO we should stop using this kind of constructions because they
> > are ugly and what's more important not portable.
> 
> They are ugly I agree - but not portable - really ? The whole point is to make
> this work on BE w/o changing the src code - this details remains hidden in an
> obscure header.

That's what I learned the hard way.
At least I was beaten a couple of times yet in both Linux kernel community and
U-Boot
one.

> > Even though we have it now working for both LE and BE configurations
> > it won't work for 64-bit cores. We'll need to add ifdeffed 32-bit paddings
> > then which will make that construction even more ugly.
> 
> When we get to 64-bit a lot things would have to change - and possibly the 
> aux reg
> layout. There is no way to make this exact code 64-bit ready !

Probably but as of now I believe use of offsets for bit-fields is the safest
approach which makes code ugly as well but at least that way we reduce risk
of erroneous copy-paste in "mirrored" part.

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

Re: modules still have .debug_* (was Re: [PATCH 0/3] ARC unwinder switch to .eh_frame)

[Alexey Brodkin]

Hi Daniel,

On Thu, 2016-09-22 at 15:37 -0700, Daniel Mentz wrote:
> On Thu, Sep 22, 2016 at 1:59 PM, Vineet Gupta
>  wrote:
> > 
> > Hi Daniel,
> > 
> > On 09/19/2016 06:21 PM, Daniel Mentz wrote:
> > > 
> > > I confirmed that the .eh_frame section is present and that the
> > > .debug_frame section is absent. I also verified that the file size of
> > > the .ko files are small enough for our embedded platform and that
> > > unnecessary sections like .debug_info, .debug_line, .debug_str etc.
> > > are also absent.
> > 
> > BTW it seems with my latest set of patches, modules still have .debug_*.
> > Can you double check if your tree still has the interim patch which added a 
> > linker
> > script for modules to strip out .debug_*
> > 
> > http://lists.infradead.org/pipermail/linux-snps-arc/2016-September/001483.html
> 
> Hi Vineet,
> 
> Sorry, that was a misunderstanding. Buildroot routinely runs the strip
> command on .ko files before installing them on the target. I was only
> looking at the .ko files *after* running the strip command. No, the
> interim patch was not in my tree.

Well are you sure buildroot really touches modules in Linux kernel build folder?
Buildroot just runs a simple "make" command in "output/build/linux-x.y".

And only on installation step Buildroot strips binaries in "output/target" 
folder.
Moreover starting from that commit
https://git.buildroot.net/buildroot/commit/?id=10c4d27aef4dca01572cfc8146cbfd194a1a85e4
even on Linux installation step Buildroot reuses kernel's module stripping 
infrastructure
but again that happens only on target.

Just in case that's what I see when building MSDOSFS as module.

In build folder:
->8---
arc-linux-readelf -S build/linux-4.7.3/fs/fat/msdos.ko
There are 38 section headers, starting at offset 0x2a630:

Section Headers:
  [Nr] Name  TypeAddr OffSize   ES Flg Lk Inf Al
  [ 0]   NULL 00 00 00  0   0  0
  [ 1] .note.gnu.build-i NOTE 34 24 00   A  0   0  4
  [ 2] .text PROGBITS 58 0013a8 00  AX  0   0  4
  [ 3] .rela.textRELA 01c774 000600 0c   I 35   2  4
  [ 4] .init.textPROGBITS 001400 10 00  AX  0   0  4
  [ 5] .rela.init.text   RELA 01cd74 18 0c   I 35   4  4
  [ 6] .exit.textPROGBITS 001410 10 00  AX  0   0  4
  [ 7] .rela.exit.text   RELA 01cd8c 18 0c   I 35   6  4
  [ 8] .rodata   PROGBITS 001440 000100 00   A  0   0 64
  [ 9] .rela.rodata  RELA 01cda4 78 0c   I 35   8  4
  [10] .modinfo  PROGBITS 001540 90 00   A  0   0  4
  [11] .rodata.str1.4PROGBITS 0015d0 30 01 AMS  0   0  4
  [12] .data PROGBITS 001600 2c 00  WA  0   0  4
  [13] .rela.dataRELA 01ce1c 30 0c   I 35  12  4
  [14] .gnu.linkonce.thi PROGBITS 001640 000140 00  WA  0   0 64
  [15] .rela.gnu.linkonc RELA 01ce4c 0c 0c   I 35  14  4
  [16] .tdataPROGBITS 001780 00 00 WAT  0   0  1
  [17] .tbss NOBITS   001780 00 00 WAT  0   0  1
  [18] .bss  NOBITS   001780 00 00  WA  0   0  1
  [19] .comment  PROGBITS 001780 78 01  MS  0   0  1
  [20] .note.GNU-stack   PROGBITS 0017f8 00 00  0   0  1
  [21] .debug_arangesPROGBITS 0017f8 48 00  0   0  1
  [22] .rela.debug_arang RELA 01ce58 3c 0c   I 35  21  4
  [23] .debug_info   PROGBITS 001840 00eaa9 00  0   0  1
  [24] .rela.debug_info  RELA 01ce94 00a53c 0c   I 35  23  4
  [25] .debug_abbrev PROGBITS 0102e9 0008b3 00  0   0  1
  [26] .debug_line   PROGBITS 010b9c 001d4d 00  0   0  1
  [27] .rela.debug_line  RELA 0273d0 001818 0c   I 35  26  4
  [28] .debug_frame  PROGBITS 0128ec 0002d8 00  0   0  4
  [29] .rela.debug_frame RELA 028be8 000168 0c   I 35  28  4
  [30] .debug_strPROGBITS 012bc4 008485 01  MS  0   0  1
  [31] .debug_locPROGBITS 01b049 000b49 00  0   0  1
  [32] .rela.debug_loc   RELA 028d50 001308 0c   I 35  31  4
  [33] .debug_ranges PROGBITS 01bb92 0001f8 00  0   0  1
  [34] .rela.debug_range RELA 02a058 000480 0c   I 35  33  4
  [35] .symtab   SYMTAB   01bd8c 0005e0 10 36  53  4
  [36] .strtab   STRTAB   01c36c 000407 00  0   0  1
  [37] .shstrtab 

Re: [PATCH] ARC: Change ld.as instruction to regular ld.

[Alexey Brodkin]

Hi Liav,

On Wed, 2016-08-17 at 09:23 +0300, Liav Rehana wrote:
> From: Liav Rehana <li...@mellanox.com>
> 
> User mode callee regs are explicitly collected before signal delivery
> or breakpoint trap. r25 is special for kernel as it serves as task
> pointer, so user mode value is clobbered very early. It is saved in
> pt_regs where generally only scratch (caller saved) res are saved.
> The code to access the corresponding pt_regs location had a subtle bug
> as it was using load/store with scaling of offset, whereas the offset
> was already byte wise correct. So fix this by replacing LD.AS with a
> standard LD
> 
> Signed-off-by: Liav Rehana <li...@mellanox.com>

That nice patch really fixes quite annoying issue when r25 got
printed improperly in gdb!

So

Tested-by: Alexey Brodkin <abrod...@synopsys.com>
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH] tools lib: Reinstate strlcpy() header guard with __UCLIBC__

[Alexey Brodkin]

Hi Arnaldo,

On Fri, 2016-08-19 at 20:02 -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Aug 19, 2016 at 06:42:07PM -0300, Arnaldo Carvalho de Melo escreveu:
> > 
> > Em Fri, Aug 19, 2016 at 02:27:58PM -0700, Vineet Gupta escreveu:
> > > 
> > > On 08/19/2016 02:10 PM, Arnaldo Carvalho de Melo wrote:
> > > > 
> > > > > 
> > > > > But one question: when you test build, do you have any extra devel
> > > > > > 
> > > > > > packages installed besides what is in this prebuilt toolchain 
> > > > > > tarball?
> > > > > > 
> > > > > > I'll add at least zlib and elfutils to the mix, building it in the
> > > > > > docker image creation process, and then testing with/without
> > > > > > NO_LIBELF=1, as I do to other cross-building images:
> > > > Trying to build elfutils 0.166:
> > > > 
> > > > checking whether gcc accepts -Wduplicated-cond... no
> > > > checking whether gcc accepts -Wnull-dereference... no
> > > > configure: WARNING: "libc does not have argp"
> > > > checking for argp_parse in -largp... no
> > > > configure: error: "no libargp found"
> > > > 
> > > > 
> > > > 
> > > > will go errands now, will try to check what is needed to build elfutils
> > > > with uclibc, ideas?
> > > 
> > > So back in 3.2 days I ran into these issues with elfutils - the 
> > > workaround was to
> > > use the standalone libelf
> > > http://www.mr511.de/software/libelf-0.8.9.tar.gz.
> > 
> > Ok, so I'll git it a try with libelf, lets see...
> 
> Argh, give up, now it is refusing to build shared libraries:
> 
>   checking for native ELF system... no
>   configure: warning: shared libraries not supported for arc-snps-linux-uclibc
> 
> And also it says ELF64 isn't support and thus GElf, some more details,
> anyway.
>   
> > 
> > > 
> > > Not sure if you will be willing to take that path.
> > > 
> > > OTOH, you could use standalone argp @ 
> > > http://www.lysator.liu.se/~nisse/archive but
> > > it seems that requires a bunch of patches too - from looking into the
> 
> > 
> > > 
> > > corresponding buildroot package folder. Give this a shot - otherwise it 
> > > is easier
> > > to just build a custom toolchain with pre-req packages from buildroot. Or 
> > > can be
> > > provided if you so deem fit !
> 
> Please, if you do that, then I'll be able to test more stuff, I already
> had enough fun trying to get elfutils, argp-standalone and libelf built
> on this env :-\

Please find a tarball with prebuilt toolchain for ARC HS38 by that link:
https://www.dropbox.com/s/uvqla26pmq03h5u/br-2016.08-rc2-65-g11109fd-archs38.tar.gz?dl=0

Just FYI I built it from today's BR sources, i.e. this is gcc6 based with all 
latest fixes
for ARC on top of vanilla gcc 6.1.1.

That's a defconfig I used in Buildroot:
>8-
BR2_arcle=y
BR2_archs38=y
BR2_TOOLCHAIN_BUILDROOT_INET_RPC=y
BR2_TOOLCHAIN_BUILDROOT_LOCALE=y
BR2_PACKAGE_ELFUTILS=y
>8-

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

Re: [LEDE-DEV] DHCP via bridge in case of IPv4

[Alexey Brodkin]

Hello,

On Mon, 2016-07-11 at 06:15 +, Alexey Brodkin wrote:
> Hi Russel,
> 
> On Sun, 2016-07-10 at 00:19 -0700, Russell Senior wrote:
> > 
> > > > > > > "Alexey" == Alexey Brodkin <alexey.brod...@synopsys.com> writes:
> > Alexey> Hi Aaron,
> > Alexey> On Sat, 2016-07-09 at 07:47 -0400, Aaron Z wrote:
> > > 
> > > > On Sat, Jul 9, 2016 at 4:37 AM, Alexey Brodkin
> > > > <alexey.brod...@synopsys.com> wrote:
> > > > > 
> > > > > Hello,
> > > > > 
> > > > > I was playing with quite simple bridged setup on different boards
> > > > with > very recent kernels (4.6.3 as of this writing) and found one
> > > > interesting > behavior that I cannot yet understand and googling
> > > > din't help here as well.
> > > > > 
> > > > > My setup is pretty simple: >
> > > > -   --   -
> > > > > 
> > > > > > HOST  |   | "Dumb AP"  |   | Wireless
> > > > client   | > > with DHCP |<->(eth0) (wlan0)<->|
> > > > attempting to | > > server|   |\ br0
> > > > / |   | get settings via DHCP | >
> > > > -   --   -
> > > > > * HOST is my laptop with DHCP server that works for sure.  > *
> > > > "Dumb AP" is a separate board (I tried ARM-based Wandboard and
> > > > ARC-based >   AXS10x boards but results are exactly the same) with
> > > > wired (eth0) and wireless >   (wlan0) network controllers bridged
> > > > together (br0). That "br0" bridge flawlessly >   gets its settings
> > > > from DHCP server on host.  > * Wireless client could be either a
> > > > smatrphone or another laptop etc but >   what's important it should
> > > > be configured to get network settings by DHCP as well.
> > > > > 
> > > > > So what happens "br0" always gets network settings from DHCP server
> > > > on HOST.  > That's fine. But wireless client only reliably gets
> > > > settings from DHCP server > if IPv6 is enabled on "Dumb AP" board. If
> > > > IPv6 is disabled I may see that > wireless client sends "DHCP
> > > > Discover" then server replies with "DHCP Offer" but > that offer
> > > > never reaches wireless client.
> > > > 
> > > > Do you have WDS enabled? If not, DHCP has issues in that scenario:
> > > > https://wiki.openwrt.org/doc/howto/clientmode
> > If the Dumb AP's wireless interface is in ap-mode, then this shouldn't
> > be an issue.  It's only client-mode interfaces that have trouble with 
> > bridging.
> > 
> > I'd suggest running tcpdump on the Dumb AP's wireless interface and the
> > client's wireless interface and see which of them sees the various parts
> > of the DHCP handshake.
> 
> So I did but for DHCP server and wireless client (had no tcpdump on Dump AP
> at the moment).
> 
> That's what I see on the server:
> ->8---
> No. TimeSource Destination  Protocol Length Info
>  3 0.151181000  0.0.0.0255.255.255.255  DHCP 342DHCP Discover - 
> Transaction ID 0x31dc321f
> 11 2.760796000  10.42.0.1  10.42.0.13   DHCP 342DHCP Offer- 
> Transaction ID 0x31dc321f
> 14 5.220985000  0.0.0.0255.255.255.255  DHCP 342DHCP Discover - 
> Transaction ID 0x31dc321f
> 15 5.22115  10.42.0.1  10.42.0.13   DHCP 342DHCP Offer- 
> Transaction ID 0x31dc321f
> 23 15.649835000 0.0.0.0255.255.255.255  DHCP 342DHCP Discover - 
> Transaction ID 0x31dc321f
> 24 15.650017000 10.42.0.1  10.42.0.13   DHCP 342DHCP Offer- 
> Transaction ID 0x31dc321f
> 32 25.648589000 0.0.0.0255.255.255.255  DHCP 342DHCP Discover - 
> Transaction ID 0x31dc321f
> 33 25.648758000 10.42.0.1  10.42.0.13   DHCP 342DHCP Offer- 
> Transaction ID 0x31dc321f
> 43 35.864567000 0.0.0.0255.255.255.255  DHCP 342DHCP Discover - 
> Transaction ID 0x31dc321f
> 48 38.832837000 10.42.0.1  10.42.0.13   DHCP 342DHCP Offer- 
> Transaction ID 0x31dc321f
> ->8---
> 
> That's on the wireless client:
> ->8

[PATCH v2] arc: Add "model" properly in device tree description of all boards

[Alexey Brodkin]

As it was discussed quite some time ago (see
https://lkml.org/lkml/2015/11/5/862) it's a good practice to add
"model" property in .dts. Moreover as per ePAPR "model" property is
required and should look like "manufacturer,model" so we do here.

Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
Cc: Vineet Gupta <vgu...@synopsys.com>
Cc: Jonas Gorski <jonas.gor...@gmail.com>
Cc: Arnd Bergmann <a...@arndb.de>
Cc: Rob Herring <r...@kernel.org>
Cc: Christian Ruppert <christian.rupp...@alitech.com>
---

Changes v1 -> v2:
 * Added "hs" postfix for boards based on ARC HS core
 * Added "archs" postfix in VDK's .dts to distinguish VDKs for
   ARC cores from those for ARM cores

 arch/arc/boot/dts/abilis_tb100_dvk.dts | 1 +
 arch/arc/boot/dts/abilis_tb101_dvk.dts | 1 +
 arch/arc/boot/dts/axs101.dts   | 1 +
 arch/arc/boot/dts/axs103.dts   | 1 +
 arch/arc/boot/dts/axs103_idu.dts   | 1 +
 arch/arc/boot/dts/nsim_700.dts | 1 +
 arch/arc/boot/dts/nsim_hs.dts  | 1 +
 arch/arc/boot/dts/nsim_hs_idu.dts  | 1 +
 arch/arc/boot/dts/nsimosci.dts | 1 +
 arch/arc/boot/dts/nsimosci_hs.dts  | 1 +
 arch/arc/boot/dts/nsimosci_hs_idu.dts  | 1 +
 arch/arc/boot/dts/vdk_hs38.dts | 1 +
 arch/arc/boot/dts/vdk_hs38_smp.dts | 1 +
 13 files changed, 13 insertions(+)

diff --git a/arch/arc/boot/dts/abilis_tb100_dvk.dts 
b/arch/arc/boot/dts/abilis_tb100_dvk.dts
index 3dd6ed9..3acf04d 100644
--- a/arch/arc/boot/dts/abilis_tb100_dvk.dts
+++ b/arch/arc/boot/dts/abilis_tb100_dvk.dts
@@ -24,6 +24,7 @@
 /include/ "abilis_tb100.dtsi"
 
 / {
+   model = "abilis,tb100";
chosen {
bootargs = "earlycon=uart8250,mmio32,0xff10,9600n8 
console=ttyS0,9600n8";
};
diff --git a/arch/arc/boot/dts/abilis_tb101_dvk.dts 
b/arch/arc/boot/dts/abilis_tb101_dvk.dts
index 1cf51c2..37d88c5 100644
--- a/arch/arc/boot/dts/abilis_tb101_dvk.dts
+++ b/arch/arc/boot/dts/abilis_tb101_dvk.dts
@@ -24,6 +24,7 @@
 /include/ "abilis_tb101.dtsi"
 
 / {
+   model = "abilis,tb101";
chosen {
bootargs = "earlycon=uart8250,mmio32,0xff10,9600n8 
console=ttyS0,9600n8";
};
diff --git a/arch/arc/boot/dts/axs101.dts b/arch/arc/boot/dts/axs101.dts
index 3f9b058..d9b9b9d 100644
--- a/arch/arc/boot/dts/axs101.dts
+++ b/arch/arc/boot/dts/axs101.dts
@@ -13,6 +13,7 @@
 /include/ "axs10x_mb.dtsi"
 
 / {
+   model = "snps,axs101";
compatible = "snps,axs101", "snps,arc-sdp";
 
chosen {
diff --git a/arch/arc/boot/dts/axs103.dts b/arch/arc/boot/dts/axs103.dts
index e6d0e31..ec7fb27 100644
--- a/arch/arc/boot/dts/axs103.dts
+++ b/arch/arc/boot/dts/axs103.dts
@@ -16,6 +16,7 @@
 /include/ "axs10x_mb.dtsi"
 
 / {
+   model = "snps,axs103";
compatible = "snps,axs103", "snps,arc-sdp";
 
chosen {
diff --git a/arch/arc/boot/dts/axs103_idu.dts b/arch/arc/boot/dts/axs103_idu.dts
index f999fef..070c297 100644
--- a/arch/arc/boot/dts/axs103_idu.dts
+++ b/arch/arc/boot/dts/axs103_idu.dts
@@ -16,6 +16,7 @@
 /include/ "axs10x_mb.dtsi"
 
 / {
+   model = "snps,axs103-smp";
compatible = "snps,axs103", "snps,arc-sdp";
 
chosen {
diff --git a/arch/arc/boot/dts/nsim_700.dts b/arch/arc/boot/dts/nsim_700.dts
index 6397051..ce0ccd20 100644
--- a/arch/arc/boot/dts/nsim_700.dts
+++ b/arch/arc/boot/dts/nsim_700.dts
@@ -10,6 +10,7 @@
 /include/ "skeleton.dtsi"
 
 / {
+   model = "snps,nsim";
compatible = "snps,nsim";
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arc/boot/dts/nsim_hs.dts b/arch/arc/boot/dts/nsim_hs.dts
index bf05fe5..3772c40 100644
--- a/arch/arc/boot/dts/nsim_hs.dts
+++ b/arch/arc/boot/dts/nsim_hs.dts
@@ -10,6 +10,7 @@
 /include/ "skeleton_hs.dtsi"
 
 / {
+   model = "snps,nsim_hs";
compatible = "snps,nsim_hs";
#address-cells = <2>;
#size-cells = <2>;
diff --git a/arch/arc/boot/dts/nsim_hs_idu.dts 
b/arch/arc/boot/dts/nsim_hs_idu.dts
index 99eabe1..48434d7c 100644
--- a/arch/arc/boot/dts/nsim_hs_idu.dts
+++ b/arch/arc/boot/dts/nsim_hs_idu.dts
@@ -10,6 +10,7 @@
 /include/ "skeleton_hs_idu.dtsi"
 
 / {
+   model = "snps,nsim_hs-smp";
compatible = "snps,nsim_hs";
interrupt-parent = <_intc>;
 
diff --git a/arch/arc/boot/dts/nsimosci.dts b/arch/arc/boot/dts/nsimosci.dts
index e659a34..bcf6031 100644
--- a/arch/arc/boot/dts/nsimosci.dts
+++ b/arch/arc/boot/dts/nsimosci.dts
@@ -10,6 +10,7 @@
 /include/ "skeleton.dtsi"
 
 / {
+   model = "snps,nsimosci";
compatible = "snps,nsimosci";
#address-cells = 

[PATCH] arc: Add "model" properly in device tree description of all boards

[Alexey Brodkin]

As it was discussed quite some time ago (see
https://lkml.org/lkml/2015/11/5/862) it's a good practice to add
"model" property in .dts. Moreover as per ePAPR "model" property is
required and should look like "manufacturer,model" so we do here.

Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
Cc: Vineet Gupta <vgu...@synopsys.com>
Cc: Jonas Gorski <jonas.gor...@gmail.com>
Cc: Arnd Bergmann <a...@arndb.de>
Cc: Rob Herring <r...@kernel.org>
Cc: Christian Ruppert <christian.rupp...@alitech.com>
---
 arch/arc/boot/dts/abilis_tb100_dvk.dts | 1 +
 arch/arc/boot/dts/abilis_tb101_dvk.dts | 1 +
 arch/arc/boot/dts/axs101.dts   | 1 +
 arch/arc/boot/dts/axs103.dts   | 1 +
 arch/arc/boot/dts/axs103_idu.dts   | 1 +
 arch/arc/boot/dts/nsim_700.dts | 1 +
 arch/arc/boot/dts/nsim_hs.dts  | 1 +
 arch/arc/boot/dts/nsim_hs_idu.dts  | 1 +
 arch/arc/boot/dts/nsimosci.dts | 1 +
 arch/arc/boot/dts/nsimosci_hs.dts  | 1 +
 arch/arc/boot/dts/nsimosci_hs_idu.dts  | 1 +
 arch/arc/boot/dts/vdk_hs38.dts | 1 +
 arch/arc/boot/dts/vdk_hs38_smp.dts | 1 +
 13 files changed, 13 insertions(+)

diff --git a/arch/arc/boot/dts/abilis_tb100_dvk.dts 
b/arch/arc/boot/dts/abilis_tb100_dvk.dts
index 3dd6ed9..3acf04d 100644
--- a/arch/arc/boot/dts/abilis_tb100_dvk.dts
+++ b/arch/arc/boot/dts/abilis_tb100_dvk.dts
@@ -24,6 +24,7 @@
 /include/ "abilis_tb100.dtsi"
 
 / {
+   model = "abilis,tb100";
chosen {
bootargs = "earlycon=uart8250,mmio32,0xff10,9600n8 
console=ttyS0,9600n8";
};
diff --git a/arch/arc/boot/dts/abilis_tb101_dvk.dts 
b/arch/arc/boot/dts/abilis_tb101_dvk.dts
index 1cf51c2..37d88c5 100644
--- a/arch/arc/boot/dts/abilis_tb101_dvk.dts
+++ b/arch/arc/boot/dts/abilis_tb101_dvk.dts
@@ -24,6 +24,7 @@
 /include/ "abilis_tb101.dtsi"
 
 / {
+   model = "abilis,tb101";
chosen {
bootargs = "earlycon=uart8250,mmio32,0xff10,9600n8 
console=ttyS0,9600n8";
};
diff --git a/arch/arc/boot/dts/axs101.dts b/arch/arc/boot/dts/axs101.dts
index 3f9b058..d9b9b9d 100644
--- a/arch/arc/boot/dts/axs101.dts
+++ b/arch/arc/boot/dts/axs101.dts
@@ -13,6 +13,7 @@
 /include/ "axs10x_mb.dtsi"
 
 / {
+   model = "snps,axs101";
compatible = "snps,axs101", "snps,arc-sdp";
 
chosen {
diff --git a/arch/arc/boot/dts/axs103.dts b/arch/arc/boot/dts/axs103.dts
index e6d0e31..ec7fb27 100644
--- a/arch/arc/boot/dts/axs103.dts
+++ b/arch/arc/boot/dts/axs103.dts
@@ -16,6 +16,7 @@
 /include/ "axs10x_mb.dtsi"
 
 / {
+   model = "snps,axs103";
compatible = "snps,axs103", "snps,arc-sdp";
 
chosen {
diff --git a/arch/arc/boot/dts/axs103_idu.dts b/arch/arc/boot/dts/axs103_idu.dts
index f999fef..070c297 100644
--- a/arch/arc/boot/dts/axs103_idu.dts
+++ b/arch/arc/boot/dts/axs103_idu.dts
@@ -16,6 +16,7 @@
 /include/ "axs10x_mb.dtsi"
 
 / {
+   model = "snps,axs103-smp";
compatible = "snps,axs103", "snps,arc-sdp";
 
chosen {
diff --git a/arch/arc/boot/dts/nsim_700.dts b/arch/arc/boot/dts/nsim_700.dts
index 6397051..ce0ccd20 100644
--- a/arch/arc/boot/dts/nsim_700.dts
+++ b/arch/arc/boot/dts/nsim_700.dts
@@ -10,6 +10,7 @@
 /include/ "skeleton.dtsi"
 
 / {
+   model = "snps,nsim";
compatible = "snps,nsim";
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arc/boot/dts/nsim_hs.dts b/arch/arc/boot/dts/nsim_hs.dts
index bf05fe5..fa6fde8 100644
--- a/arch/arc/boot/dts/nsim_hs.dts
+++ b/arch/arc/boot/dts/nsim_hs.dts
@@ -10,6 +10,7 @@
 /include/ "skeleton_hs.dtsi"
 
 / {
+   model = "snps,nsim";
compatible = "snps,nsim_hs";
#address-cells = <2>;
#size-cells = <2>;
diff --git a/arch/arc/boot/dts/nsim_hs_idu.dts 
b/arch/arc/boot/dts/nsim_hs_idu.dts
index 99eabe1..1f02808 100644
--- a/arch/arc/boot/dts/nsim_hs_idu.dts
+++ b/arch/arc/boot/dts/nsim_hs_idu.dts
@@ -10,6 +10,7 @@
 /include/ "skeleton_hs_idu.dtsi"
 
 / {
+   model = "snps,nsim-smp";
compatible = "snps,nsim_hs";
interrupt-parent = <_intc>;
 
diff --git a/arch/arc/boot/dts/nsimosci.dts b/arch/arc/boot/dts/nsimosci.dts
index e659a34..bcf6031 100644
--- a/arch/arc/boot/dts/nsimosci.dts
+++ b/arch/arc/boot/dts/nsimosci.dts
@@ -10,6 +10,7 @@
 /include/ "skeleton.dtsi"
 
 / {
+   model = "snps,nsimosci";
compatible = "snps,nsimosci";
#address-cells = <1>;
#size-cells = <1>;
diff --git a/arch/arc/boot/dts/nsimosci_hs.dts 
b/arch/arc/boot/dts/nsimosci_hs.dts
index 16ce5d6..6609240 100644
--- a/arch/arc/boot/dts/nsimosci_hs.dts
+++ b/a

Re: ARC stable backport request

[Alexey Brodkin]

Hi Greg,

On Sun, 2016-08-14 at 17:39 +0200, Greg KH wrote:
> On Wed, May 25, 2016 at 05:13:31PM +0530, Vineet Gupta wrote:
> > 
> > Hi,
> > 
> > Can we please backport a6416f57ce57fb390b "ARC: use ASL assembler mnemonic".
> > Newer binutils don't like ASL instruction and fail to build kernels prior 
> > to v4.4
> > which added this fix.
> 
> Fails to apply to 3.14-stable :(

Looks like it's there already. Isn't it?
http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/arch/arc?h=linux-3.14.y=8ba2f5328c2c9859bb
bf412e5804974483d66e9d

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

Re: Problems building arc-2016.09-eng007 toolchain with 2.6.35 kernel headers

[Alexey Brodkin]

Hi Waldemar,

On Wed, 2016-08-10 at 19:03 +0200, Waldemar Brodkorb wrote:
> Hi,
> Vineet Gupta wrote,
> 
> > 
> > On 08/08/2016 02:44 PM, Petri Gynther wrote:
> > > 
> > > uclibc-ng & ARC developers:
> > > 
> > > I'm trying to use buildroot to build the latest ARC toolchain
> > > (arc-2016.09-eng007) against our vendor-provided 2.6.35.12 ARC Linux
> > > kernel. (Yes, it is an ancient kernel, but that's what I have to work
> > > with for now, unfortunately.)
> > > 
> > > ...
> > > 
> > > 
> > > Questions:
> > > 1) Does the latest ARC toolchain use some new ABI for binaries that
> > > makes them incompatible with 2.6.35.12 kernel?
> > 
> > Indeed even if you were to build it successfully - you will run into ABI 
> > issues -
> > 2.6.35 is ABI v1 and we are currently at v3 (which is going to change soon 
> > even
> > further to v4 - for ARC HS processors)
> > More details at:
> > https://github.com/foss-for-synopsys-dwc-arc-processors/linux/wiki/ARC-Linux-Syscall-ABI-Compatibility
> > 
> > > 
> > > 2) Is uclibc-ng 1.0.17 supposed to be compatible with 2.6.x kernel 
> > > headers?
> > 
> > No - modern/upstream uClibc-ng is not compatible with 2.6.35
> > You need to use the uClibc of the time - with pairing gcc/binutils - 
> > although that
> > will be a can of worms
> 
> This is only the case for ARC, right?
> Other architectures should work fine, like MIPS or ARM.

As Vineet mentioned above that's the case for ARC because of ABI changes, see
Wiki page above.

As for arches that were supported in Linux for much longer time like ARM and 
MISP most
probably up-to-date uClibc would work with 2.6.x kernels but frankly I haven't 
tried that
myself.

Still newer arches like Nios and Extensa may have similar issues as we have.
But again I barely have any experience with those arches so asking their 
maintainers
might be a good idea.

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

Re: dmatest no longer works on ARC SDP with DW DMAC

[Alexey Brodkin]

Hi Andy,

On Wed, 2016-08-10 at 15:15 +0300, Andy Shevchenko wrote:
> On Wed, 2016-08-10 at 11:06 +, Eugeniy Paltsev wrote:
> > 
> > dmatest on ARC SDP with DW DMAC became broken after df5c7386
> > ("dmaengine: dw: some Intel devices has no memcpy support") and
> > 30cb2639 ("dmaengine: dw: don't override platform data with autocfg")
> > commits.
> > * After df5c7386 commit "DMA_MEMCPY" capability option doesn't
> > get set correctly in platform driver version.
> > * After 30cb2639 commit
> > "data_width" and "nollp" parameters don't get set correctly in
> > platform
> > driver version.
> > 
> > This happens because in old driver version there are three sources 
> > of parameters: pdata, device tree and autoconfig hardware registers. 
> > Some parameters were read from pdata and others from autoconfig
> > hardware registers. If pdata was absent some pdata structure 
> > fields were filled with parameters from device tree. But 30cb2639
> > commit disabled overriding pdata with autocfg, so if we use platform
> > driver version without pdata some parameters will not be set.
> 
> Yes, that's correct behaviour right now. You have to provide platform
> code which registers device with all platform data provided.

But given autocfg registers exist in HW why don't we rely on their contents?

> > I'm wondering what would be the best way to fix this situation?
> 
> Ideally we have to switch to use built-in device properties
> (drivers/base/property.c) and platform code in your case has to provide
> properties.

What do you mean saying "built-in device properties"?
Setting pdata structure? In our particular case we use device tree
for DW DMAC setup.

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

Re: Build failure in linux mainline when building arcv2 images

[Alexey Brodkin]

Hi Vineet, Guenter,

On Fri, 2016-07-29 at 21:27 -0700, Guenter Roeck wrote:
> On 07/29/2016 03:46 PM, Vineet Gupta wrote:
> 
> > 
> > What you want is
> > 2016-05-19 09439560b9f9 toolchain: bump ARC tools to arc-2016.03 release
> > 
> > which seems to be present in released 2016.05, but when I checkout 2016.05 
> > tag (or
> > aa6fd11feebff) that patch is not there !
> > 
> 
> A toolchain build off SHA 09439560b9f9 works.

Indeed we were a little-bit too late for BR 2016.05 release with
our toolchain bump so the patch in question only made its way in BR repo
right after BR release.

Anyways good to know your issue is resolved now.

Note with arc-2016.03 we still see a lot of issues here and there
because that's the first version that uses our rewritten from scratch binutils
(the base for binutils port upstreaming for ARC). And so in BR we continue to
update ARC tools to so-called engineering builds of our current development
branches of gcc and binutils. That information might be useful if you face any
other issues building stuff for ARC.

Or don't hesitate to email us so we'll try to point you to something that
should work :)

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

Re: [PATCH 0/2] ARC Moving to @pcl relocations

[Alexey Brodkin]

Hi Andrew, all,

On Thu, 2016-07-28 at 15:40 -0700, Vineet Gupta wrote:
> On 07/28/2016 03:04 PM, Bernhard Reutner-Fischer wrote:
> > 
> > > 
> > > Indeed your 2/2 seems to be the most "past-proof" code change. So I
> > > > 
> > > > would think it
> > > > is indeed better and is something I should have done in the first
> > > > place.
> > > > 
> > > > @Alexey, @Vlad what say you ?
> > uClibc traditionally supports the current stable release of binutils, which 
> > would make it patch #1 I think.
> > 
> 
> But 2/2 works for both and makes actual binutils version moot. FWIW, ARC tools
> don't as of last release didn't use the upstream/stable binutils, but we are
> pretty close to that now though.

Personally I'd prefer to not add more conditional defines in uClibc but
make it a little-bit simpler.

I.e. either Vlad's patch or #1 from this series IMHO looks better.
It's been quite some time since we updated our tools with PCL support
and I'm not really sure if there's anybody interested in using ages old
tools with today's uClibc. We don't test such combinations and there could
be issues already in such combos.

BTW I noticed that Vlad's patch removes/reverts that thing as well:
http://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/ldso/ldso/arc/dl-sysdep.h?id=181d410ad00cddd1d6c9f4835e129136b74
c5187

While Andrew just replaces ".&" construction with "@pcl".
I'm wondering which is the correct approach here?

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

Re: [LEDE-DEV] DHCP via bridge in case of IPv4

[Alexey Brodkin]

Hi Russel,

On Sun, 2016-07-10 at 00:19 -0700, Russell Senior wrote:
> > 
> > > 
> > > > 
> > > > > 
> > > > > > 
> > > > > > "Alexey" == Alexey Brodkin <alexey.brod...@synopsys.com> writes:
> Alexey> Hi Aaron,
> Alexey> On Sat, 2016-07-09 at 07:47 -0400, Aaron Z wrote:
> > 
> > > 
> > > On Sat, Jul 9, 2016 at 4:37 AM, Alexey Brodkin
> > > <alexey.brod...@synopsys.com> wrote:
> > > > 
> > > > 
> > > > Hello,
> > > > 
> > > > I was playing with quite simple bridged setup on different boards
> > > with > very recent kernels (4.6.3 as of this writing) and found one
> > > interesting > behavior that I cannot yet understand and googling
> > > din't help here as well.
> > > > 
> > > > 
> > > > My setup is pretty simple: >
> > > -   --   -
> > > > 
> > > > > 
> > > > > 
> > > > > HOST  |   | "Dumb AP"  |   | Wireless
> > > client   | > > with DHCP |<->(eth0) (wlan0)<->|
> > > attempting to | > > server|   |\ br0
> > > / |   | get settings via DHCP | >
> > > -   --   -
> > > > 
> > > > 
> > > > * HOST is my laptop with DHCP server that works for sure.  > *
> > > "Dumb AP" is a separate board (I tried ARM-based Wandboard and
> > > ARC-based >   AXS10x boards but results are exactly the same) with
> > > wired (eth0) and wireless >   (wlan0) network controllers bridged
> > > together (br0). That "br0" bridge flawlessly >   gets its settings
> > > from DHCP server on host.  > * Wireless client could be either a
> > > smatrphone or another laptop etc but >   what's important it should
> > > be configured to get network settings by DHCP as well.
> > > > 
> > > > 
> > > > So what happens "br0" always gets network settings from DHCP server
> > > on HOST.  > That's fine. But wireless client only reliably gets
> > > settings from DHCP server > if IPv6 is enabled on "Dumb AP" board. If
> > > IPv6 is disabled I may see that > wireless client sends "DHCP
> > > Discover" then server replies with "DHCP Offer" but > that offer
> > > never reaches wireless client.
> > > 
> > > 
> > > Do you have WDS enabled? If not, DHCP has issues in that scenario:
> > > https://wiki.openwrt.org/doc/howto/clientmode
> If the Dumb AP's wireless interface is in ap-mode, then this shouldn't
> be an issue.  It's only client-mode interfaces that have trouble with 
> bridging.
> 
> I'd suggest running tcpdump on the Dumb AP's wireless interface and the
> client's wireless interface and see which of them sees the various parts
> of the DHCP handshake.

So I did but for DHCP server and wireless client (had no tcpdump on Dump AP
at the moment).

That's what I see on the server:
->8---
No. TimeSource Destination  Protocol Length Info
 3 0.151181000  0.0.0.0255.255.255.255  DHCP 342DHCP Discover - 
Transaction ID 0x31dc321f
11 2.760796000  10.42.0.1  10.42.0.13   DHCP 342DHCP Offer- 
Transaction ID 0x31dc321f
14 5.220985000  0.0.0.0255.255.255.255  DHCP 342DHCP Discover - 
Transaction ID 0x31dc321f
15 5.22115  10.42.0.1  10.42.0.13   DHCP 342DHCP Offer- 
Transaction ID 0x31dc321f
23 15.649835000 0.0.0.0255.255.255.255  DHCP 342DHCP Discover - 
Transaction ID 0x31dc321f
24 15.650017000 10.42.0.1  10.42.0.13   DHCP 342DHCP Offer- 
Transaction ID 0x31dc321f
32 25.648589000 0.0.0.0255.255.255.255  DHCP 342DHCP Discover - 
Transaction ID 0x31dc321f
33 25.648758000 10.42.0.1  10.42.0.13   DHCP 342DHCP Offer- 
Transaction ID 0x31dc321f
43 35.864567000 0.0.0.0255.255.255.255  DHCP 342DHCP Discover - 
Transaction ID 0x31dc321f
48 38.832837000 10.42.0.1  10.42.0.13   DHCP 342DHCP Offer- 
Transaction ID 0x31dc321f
->8---

That's on the wireless client:
->8---
No.  Time   Source   Destination  Protocol Length Info
1171 94.192971000   0.0.0.0  255.255.255.255  DHCP 342DHCP Discover - 
Transaction ID 0x31dc321f
1182 99.263686000   0.0.0.0  255.255.255.255  DHCP 342DHCP Discover - 
Transaction ID 0x31dc321f
1185 109.692642000  0.0.0.0  255.255.255.255  DHCP 342DHCP Discover - 
Transaction ID 0x31dc321f
1186 119.691474000  0.0.0.0  255.255.255.255  DHCP 342DHCP Discover - 
Transaction ID 0x31dc321f
1190 129.907507000  0.0.0.0  255.255.255.255  DHCP 342DHCP Discover - 
Transaction ID 0x31dc321f
->8---

I'll try to capture data from Dumb AP sometime soon and will reply to the 
thread.

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

DHCP via bridge in case of IPv4

[Alexey Brodkin]

Hello,

I was playing with quite simple bridged setup on different boards with
very recent kernels (4.6.3 as of this writing) and found one interesting
behavior that I cannot yet understand and googling din't help here as well.

My setup is pretty simple:
-   --   -
| HOST  |   | "Dumb AP"  |   | Wireless client   |
| with DHCP |<->(eth0) (wlan0)<->| attempting to |
| server|   |\ br0 / |   | get settings via DHCP |
-   --   -

* HOST is my laptop with DHCP server that works for sure.
* "Dumb AP" is a separate board (I tried ARM-based Wandboard and ARC-based
  AXS10x boards but results are exactly the same) with wired (eth0) and wireless
  (wlan0) network controllers bridged together (br0). That "br0" bridge 
flawlessly
  gets its settings from DHCP server on host.
* Wireless client could be either a smatrphone or another laptop etc but
  what's important it should be configured to get network settings by DHCP as 
well.

So what happens "br0" always gets network settings from DHCP server on HOST.
That's fine. But wireless client only reliably gets settings from DHCP server
if IPv6 is enabled on "Dumb AP" board. If IPv6 is disabled I may see that
wireless client sends "DHCP Discover" then server replies with "DHCP Offer" but
that offer never reaches wireless client.

Well actually sometimes very-very rarely that offer may reach wireless client 
but
I cannot understand how to reproduce it reliably.

Still looks like enabling of IPv6 fixes that issue.

So my question here is: why I see that difference with IPv4 vs IPv6?

One sidenote:
  Somehow I figured out that in case of IPv4 so-called routing
  cache is absent (it was removed in Linux kernel 3.6) while with IPv6 it
  still exist. And assuming my hardware is sane and no data gets lost I may
  think that it's really a routing problem and missing routing cache might
  be an answer. Still being a noob in networking stuff I'd like to get a bit
  better explanation of things I see.

All thoughts and comments are more than welcome.

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

Re: ath9k-htc on OHCI -> bogus usb xfer

[Alexey Brodkin]

Hi Oleksij,

On Wed, 2016-07-06 at 11:09 +0200, fixed-term.Oleksij.Rempel wrote:
> 
> On 06.07.2016 10:45, Alexey Brodkin wrote:
> > 
> > Hi Oleksij,
> > 
> > On Wed, 2016-07-06 at 10:38 +0200, fixed-term.Oleksij.Rempel wrote:
> > > 
> > > 
> > > On 06.07.2016 10:32, Alexey Brodkin wrote:
> > > > 
> > > > 
> > > > Hi Oleksij,
> > > > 
> > > > On Wed, 2016-07-06 at 10:24 +0200, fixed-term.Oleksij.Rempel wrote:
> > > > > 
> > > > > 
> > > > >  
> > > > > Hm... this Endpoint should be Interrupt, not Bulk. If you search for
> > > > > lsusb of this kind of adapter all of them list EP3 and EP4 as 
> > > > > Interrupt.
> > > > > 
> > > > > what did went wrong here? Is it not working in USB High Speed mode?
> > > > Unfortunately as of now on that board EHCI doesn't work.
> > > > 
> > > > That's not a problem of a particular USB device but something in either
> > > > ECHI host controller or its integration. I do hope we will fix it 
> > > > sometime soon
> > > > (this is a development board and USB controller is implemented in FPGA 
> > > > so
> > > > there's a chance to fix stuff later on).
> > > > 
> > > > So given only OHCI works on the board I went forward and attempted to 
> > > > use it
> > > > with Wi-Fi USB dongle.
> > > I did some tests for 2 years on OHCI controller on x86. There was no
> > > noticable issues. It was even a bit faster then Intels EHCI. I don't
> > > think OHCI alone is the source of this problem.
> > Well I was also surprised how well that dongle works with that board in
> > OHCI mode. I saw quite consistent ~4-5 Mbit/second rates when doing 
> > Speedtest
> > from my smartphone. So IMHO it's completely usable. Especially on that kind 
> > of
> > HW which has main CPU running at just 100MHz.
> > 
> > > 
> > > On other side, so far i know, this adapter claims to provide usb full
> > > speed support, (Not only high speed) and may use different usb
> > > descriptor for this. May be this is the problem.
> > So is there something we may do with all that?
> Sure...
> 
> This shows that EP4 is Bluk in full speed mode. And it is defined by a
> boot loader of this chip:
> grep -R USB_FS_EP4_ATTRIBUTE *
> sboot/magpie_1_1/sboot/hif/usb/src/usb_table.c:
> m2BYTE(USB_FS_EP4_ATTRIBUTE, USB_FS_EP4_MAX_PACKET_SIZE),
> sboot/magpie_1_1/sboot/hif/usb/src/usb_table.h:#define
> USB_FS_EP4_ATTRIBUTEbUSB_EP_TYPE_BULK
> sboot/magpie_1_1/inc/usb_table.h:#define USB_FS_EP4_ATTRIBUTE
>  bUSB_EP_TYPE_BULK
> target_firmware/magpie_fw_dev/target/inc/k2/usb_table.h:#define
> USB_FS_EP4_ATTRIBUTEbUSB_EP_TYPE_BULK
> target_firmware/magpie_fw_dev/target/inc/magpie/usb_table.h:#define
> USB_FS_EP4_ATTRIBUTEbUSB_EP_TYPE_BULK
> 
> 
> So, there are fallowing variants to fix it:
> a) patch full speed usb descriptor in firmware and add usb reinit
> support to the driver.
> b) add support of different EP4 types.
> 
> In any case, some one need to implement it... right now i have time only
> for mentoring.

That's understood.

> It is hard to say, which solution is better. It will affect performance
> and stability. We will need lots of testing on different HW variants to
> know it.
> May be usb maeling list can give some input here?

Let's hope so :)

> Currently we have fallowing issues:
> - if EP4 and EP3 are Interrupt, it works slower on High Speed controller.
> - if EP4 and EP3 are Bulk, the work better on High Speed and brake on
> Super Speed controllers. This adapter support my 64B packets and if we
> have more, fifo of this adapter will overrun.
> - Full Speed is currently unknown field for me, and it looks like it was
> never actually working properly.

But given that dongle seem to work fine with muted warning do you think it's
fine to continue that way or not?

I mean if there's a chance this "bogus usb xfer" might affect something during
execution? Otherwise if that's just not a crucial problem or not a problem at 
all
may be we may just think how to make this warning not so annoying (in my case
I saw never ending flood of those warnings so that basically stopped me from 
using
the board after that warning started to appear.

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

Re: ath9k-htc on OHCI -> bogus usb xfer

[Alexey Brodkin]

Hi Oleksij,

On Tue, 2016-07-05 at 21:01 +0200, Oleksij Rempel wrote:
> Am 05.07.2016 um 19:31 schrieb Alexey Brodkin:
> > 
> > Hi Oleksij,
> > 
> > On Tue, 2016-07-05 at 19:23 +0200, Oleksij Rempel wrote:
> > > 
> > > Hi,
> > > 
> > > Am 05.07.2016 um 14:20 schrieb Alexey Brodkin:
> > > > 
> > > > 
> > > > Hello,
> > > > 
> > > > Looks like this is another manifestation of already seen problem with 
> > > > ath9k-htc
> > > > and OHCI controller.
> > > > 
> > > > I'm trying to get USB Wi-Fi dongle based on Atheros AR9271 to work with 
> > > > our
> > > > development board (this is Synopsys AXS103) and seeing a picture very 
> > > > similar to
> > > > what was discussed here 
> > > > http://thread.gmane.org/gmane.linux.usb.general/110847
> > > > 
> > > > Below is what I see on insertion of the dongle.
> > > > Note I have the most recent ath9k-htc firmware (see 
> > > > "ath9k_htc/htc_9271-1.4.0.fw"
> > > > in the log below) and Linux kernel is 4.6.3 (latest stable as of today) 
> > > > but the same
> > > > happens even on 4.4.
> > > > 
> > > > Interesting enough if I simply remove or disable the warning like that
> > > > >8---
> > > > diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c
> > > > index 3d27477..a317e1e 100644
> > > > --- a/drivers/usb/core/urb.c
> > > > +++ b/drivers/usb/core/urb.c
> > > > @@ -443,11 +443,6 @@ int usb_submit_urb(struct urb *urb, gfp_t 
> > > > mem_flags)
> > > >  * cause problems in HCDs if they get it wrong.
> > > >  */
> > > >  
> > > > -   /* Check that the pipe's type matches the endpoint's type */
> > > > -   if (usb_pipetype(urb->pipe) != pipetypes[xfertype])
> > > > -   dev_WARN(>dev, "BOGUS urb xfer, pipe %x != type 
> > > > %x\n",
> > > > -   usb_pipetype(urb->pipe), pipetypes[xfertype]);
> > > > -
> > > > /* Check against a simple/standard policy */
> > > > allowed = (URB_NO_TRANSFER_DMA_MAP | URB_NO_INTERRUPT | 
> > > > URB_DIR_MASK |
> > > > URB_FREE_BUFFER);
> > > > >8---
> > > > everything seem to work quite nice.
> > > > 
> > > > Any thoughts are much appreciated.
> > > > 
> > > > That's the log itself:
> > > > >8---
> > > > usb 1-1: new full-speed USB device number 2 using ohci-platform
> > > > usb 1-1: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw requested
> > > > usb 1-1: ath9k_htc: Transferred FW: ath9k_htc/htc_9271-1.4.0.fw, size: 
> > > > 51008
> > > > [ cut here ]
> > > > WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 
> > > > usb_submit_urb+0x162/0x404
> > > > usb 1-1: BOGUS urb xfer, pipe 1 != type 3
> > > > Modules linked in:
> > > > CPU: 0 PID: 4 Comm: kworker/0:0 Not tainted 4.6.3 #10
> > > > Workqueue: events request_firmware_work_func
> > > > 
> > > > Stack Trace:
> > > >   arc_unwind_core.constprop.1+0x94/0x10c
> > > > ---[ end trace 2249b79eac9991d1 ]---
> > > > [ cut here ]
> > > > WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 
> > > > usb_submit_urb+0x162/0x404
> > > > usb 1-1: BOGUS urb xfer, pipe 1 != type 3
> > > > Modules linked in:
> > > > CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: GW   4.6.3 #10
> > > > Workqueue: events request_firmware_work_func
> > > > 
> > > > Stack Trace:
> > > >   arc_unwind_core.constprop.1+0x94/0x10c
> > > > ---[ end trace 2249b79eac9991d2 ]---
> > > > [ cut here ]
> > > > WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 
> > > > usb_submit_urb+0x162/0x404
> > > > usb 1-1: BOGUS urb xfer, pipe 1 != type 3
> > > > Modules linked in:
> > > > CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: GW   4.6.3 #10
> > > > Workqueue: events request_firmware_work_func
> > > > 
> > >

ath9k-htc on OHCI -> bogus usb xfer

[Alexey Brodkin]

Hello,

Looks like this is another manifestation of already seen problem with ath9k-htc
and OHCI controller.

I'm trying to get USB Wi-Fi dongle based on Atheros AR9271 to work with our
development board (this is Synopsys AXS103) and seeing a picture very similar to
what was discussed here http://thread.gmane.org/gmane.linux.usb.general/110847

Below is what I see on insertion of the dongle.
Note I have the most recent ath9k-htc firmware (see 
"ath9k_htc/htc_9271-1.4.0.fw"
in the log below) and Linux kernel is 4.6.3 (latest stable as of today) but the 
same
happens even on 4.4.

Interesting enough if I simply remove or disable the warning like that
>8---
diff --git a/drivers/usb/core/urb.c b/drivers/usb/core/urb.c
index 3d27477..a317e1e 100644
--- a/drivers/usb/core/urb.c
+++ b/drivers/usb/core/urb.c
@@ -443,11 +443,6 @@ int usb_submit_urb(struct urb *urb, gfp_t mem_flags)
 * cause problems in HCDs if they get it wrong.
 */
 
-   /* Check that the pipe's type matches the endpoint's type */
-   if (usb_pipetype(urb->pipe) != pipetypes[xfertype])
-   dev_WARN(>dev, "BOGUS urb xfer, pipe %x != type %x\n",
-   usb_pipetype(urb->pipe), pipetypes[xfertype]);
-
/* Check against a simple/standard policy */
allowed = (URB_NO_TRANSFER_DMA_MAP | URB_NO_INTERRUPT | URB_DIR_MASK |
URB_FREE_BUFFER);
>8---
everything seem to work quite nice.

Any thoughts are much appreciated.

That's the log itself:
>8---
usb 1-1: new full-speed USB device number 2 using ohci-platform
usb 1-1: ath9k_htc: Firmware ath9k_htc/htc_9271-1.4.0.fw requested
usb 1-1: ath9k_htc: Transferred FW: ath9k_htc/htc_9271-1.4.0.fw, size: 51008
[ cut here ]
WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 usb_submit_urb+0x162/0x404
usb 1-1: BOGUS urb xfer, pipe 1 != type 3
Modules linked in:
CPU: 0 PID: 4 Comm: kworker/0:0 Not tainted 4.6.3 #10
Workqueue: events request_firmware_work_func

Stack Trace:
  arc_unwind_core.constprop.1+0x94/0x10c
---[ end trace 2249b79eac9991d1 ]---
[ cut here ]
WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 usb_submit_urb+0x162/0x404
usb 1-1: BOGUS urb xfer, pipe 1 != type 3
Modules linked in:
CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: GW   4.6.3 #10
Workqueue: events request_firmware_work_func

Stack Trace:
  arc_unwind_core.constprop.1+0x94/0x10c
---[ end trace 2249b79eac9991d2 ]---
[ cut here ]
WARNING: CPU: 0 PID: 4 at drivers/usb/core/urb.c:450 usb_submit_urb+0x162/0x404
usb 1-1: BOGUS urb xfer, pipe 1 != type 3
Modules linked in:
CPU: 0 PID: 4 Comm: kworker/0:0 Tainted: GW   4.6.3 #10
Workqueue: events request_firmware_work_func

Stack Trace:
  arc_unwind_core.constprop.1+0x94/0x10c
---[ end trace 2249b79eac9991d3 ]---

...
>8---

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

[PATCH] ARC: typo fix in mm/ioremap.c

[Alexey Brodkin]

Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
---
 arch/arc/mm/ioremap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arc/mm/ioremap.c b/arch/arc/mm/ioremap.c
index 49b8abd..f52b7db6 100644
--- a/arch/arc/mm/ioremap.c
+++ b/arch/arc/mm/ioremap.c
@@ -49,7 +49,7 @@ EXPORT_SYMBOL(ioremap);
 /*
  * ioremap with access flags
  * Cache semantics wise it is same as ioremap - "forced" uncached.
- * However unline vanilla ioremap which bypasses ARC MMU for addresses in
+ * However unlike vanilla ioremap which bypasses ARC MMU for addresses in
  * ARC hardware uncached region, this one still goes thru the MMU as caller
  * might need finer access control (R/W/X)
  */
-- 
2.5.5


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

Re: [PATCH] arc: warn only once if DW2_UNWIND is disabled

[Alexey Brodkin]

Hi Vineet,

On Tue, 2016-06-28 at 10:00 +0530, Vineet Gupta wrote:
> On Thursday 23 June 2016 01:30 PM, Alexey Brodkin wrote:
> > 
> > If CONFIG_ARC_DW2_UNWIND is disabled every time arc_unwind_core()
> > gets called following message gets printed in debug console:
> > ->8---
> > CONFIG_ARC_DW2_UNWIND needs to be enabled
> > ->8---
> > 
> > That message makes sense if user indeed wants to see a backtrace or
> > get nice function call-graphs in perf but what if user disabled
> > unwinder for the purpose? Why pollute his debug console?
> > 
> > So instead we'll warn user about possibly missing feature once and
> > let him decide if that was what he or she really wanted.
> > 
> > Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
> > Cc: sta...@vger.kernel.org  [3.18+]
>
> Does this really need to be stable backport ?

I think it makes perfect sense for any kernel version because
it saves debug console from being polluted with messages which
most probably have no point (Ok I disabled unwinder in kernel config,
why then spam me with proposals to enable it)?

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

Re: Patches for ARC

[Alexey Brodkin]

Hi Waldemar,

On Mon, 2016-06-13 at 22:38 +0200, Waldemar Brodkorb wrote:
> Hi Alexey,
> Alexey Brodkin wrote,
> 
> > 
> > Hi Waldemar,
> > 
> > Just saw that new change for ARC ("arc: use generic lowlevellock",
> > http://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/?id=1b49dc96d103e0151fee290d55cea55aa12c906d).
> > 
> > Even though this is very nice to see fixes and improvements done by people
> > outside Synopsys IMHO it still makes sense to add SNPS people in the loop so
> > we may review submitted patches.
> You are right, I first thought I need to add you, then I thought you
> are reading the low traffic list anyway. 
> Sorry for the trouble.
>  
> > 
> > So could you please first get an Ack from either Vineet (in Cc) or me before
> > committing stuff for ARC? Alternatively just Cc 
> > linux-snps-arc@lists.infradead.org.
> I will do in the future. Do you thing following patch would be okay
> to commit to make changes to architecture specific parts
> more formal?
>  
> > 
> > Again I'm very happy with uClibc-ng and appreciate a lot all your efforts
> > and to make uClibc-ng more robust let's review stuff together.
> > 
> > Also it was hard for me to find a relevant patch on the mailing list
> > because I was expecting patch to be sent via git "send-email" (which I think
> > should be a standard way for patch submissions in uClibc). Only going 
> > through a relevant
> > thread for ARM I found a message with attached files.
> Is the commit okay or do I need to revert it?

Sorry for late reply.

Yep this commit is fine so no need to do anything here.

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

[PATCH] arc: warn only once if DW2_UNWIND is disabled

[Alexey Brodkin]

If CONFIG_ARC_DW2_UNWIND is disabled every time arc_unwind_core()
gets called following message gets printed in debug console:
->8---
CONFIG_ARC_DW2_UNWIND needs to be enabled
->8---

That message makes sense if user indeed wants to see a backtrace or
get nice function call-graphs in perf but what if user disabled
unwinder for the purpose? Why pollute his debug console?

So instead we'll warn user about possibly missing feature once and
let him decide if that was what he or she really wanted.

Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
Cc: sta...@vger.kernel.org  [3.18+]
---
 arch/arc/kernel/stacktrace.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arc/kernel/stacktrace.c b/arch/arc/kernel/stacktrace.c
index e0efff1..b9192a6 100644
--- a/arch/arc/kernel/stacktrace.c
+++ b/arch/arc/kernel/stacktrace.c
@@ -142,7 +142,7 @@ arc_unwind_core(struct task_struct *tsk, struct pt_regs 
*regs,
 * prelogue is setup (callee regs saved and then fp set and not other
 * way around
 */
-   pr_warn("CONFIG_ARC_DW2_UNWIND needs to be enabled\n");
+   pr_warn_once("CONFIG_ARC_DW2_UNWIND needs to be enabled\n");
return 0;
 
 #endif
-- 
2.5.5


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

of_reserved_mem_device_init_by_idx() returns -EINVAL if "memory-region" is missing

[Alexey Brodkin]

Hi Marek,

We used to use of_reserved_mem_device_init() in such a context in GPU drivers:
>8---
/* Get the optional framebuffer memory resource */
ret = of_reserved_mem_device_init(drm->dev);
if (ret && ret != -ENODEV)
return ret;
>8---

The point is we may have a dedicated reserved memory area or may not have 
(depends on a particular .dts).
Our expectation is if reserved memory area is missing then 
of_reserved_mem_device_init()
just returns -ENODEV and it used to work like this.

Now with your commit 59ce4039727e "of: reserved_mem: add support for using more 
than one region for given device"
behavior is different. of_reserved_mem_device_init_by_idx() has this:
>8---
target = of_parse_phandle(np, "memory-region", idx);
if (!target)
return -EINVAL;
>8---

So I'm wondering which part should be fixed:
 1) of_reserved_mem itself or
 2) users of of_reserved_mem_device_init()

Any thoughts?

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

[GIT PULL] drm/arcpgu: Make ARC PGU usable on sim platforms

[Alexey Brodkin]

Hi Dave,

Please pull this mini-series that allows ARC PGU to be used on simulation
platforms like nSIM OSCI (AKA Linux Virtual Platform) or ARC VDK.

The series was published for review here
https://lists.freedesktop.org/archives/dri-devel/2016-June/110647.html

It is based on today's "drm-next" branch.

Best regards,
Alexey

The following changes since commit 3c85f20a289d044f303f473ee6ab7502303fc3b0:

  Merge tag 'omapdrm-4.8' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-next 
(2016-06-09
12:20:11 +1000)

are available in the git repository at:

  https://github.com/foss-for-synopsys-dwc-arc-processors/linux.git 
topic-arcpgu-sim

for you to fetch changes up to 830c6578481e3b8649261062dfc5b0ac3c9374f8:

  ARC: [nsimosci] Enable ARC PGU on nSIM OSCI virtual platforms (2016-06-13 
17:45:18 +0200)

--------
Alexey Brodkin (2):
  ARCv2: [vdk] Enable ARC PGU on HS38 VDK
  ARC: [nsimosci] Enable ARC PGU on nSIM OSCI virtual platforms

Ruud Derwig (1):
  drm/arcpgu: Make ARC PGU usable on simulation platforms

 arch/arc/boot/dts/nsimosci.dts |  14 +++---
 arch/arc/boot/dts/nsimosci_hs.dts  |  14 +++---
 arch/arc/boot/dts/nsimosci_hs_idu.dts  |  14 +++---
 arch/arc/boot/dts/vdk_axs10x_mb.dtsi   |  13 +
 arch/arc/boot/dts/vdk_hs38_smp.dts |   2 +-
 arch/arc/configs/nsimosci_defconfig|   3 ++-
 arch/arc/configs/nsimosci_hs_defconfig |   3 ++-
 arch/arc/configs/nsimosci_hs_smp_defconfig |   3 ++-
 arch/arc/configs/vdk_hs38_smp_defconfig|   7 ++-
 drivers/gpu/drm/arc/Makefile   |   2 +-
 drivers/gpu/drm/arc/arcpgu.h   |   1 +
 drivers/gpu/drm/arc/arcpgu_drv.c   |  15 ---
 drivers/gpu/drm/arc/arcpgu_sim.c   | 128


 13 files changed, 189 insertions(+), 30 deletions(-)
 create mode 100644 drivers/gpu/drm/arc/arcpgu_sim.c
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Patches for ARC

[Alexey Brodkin]

Hi Waldemar,

Just saw that new change for ARC ("arc: use generic lowlevellock",
http://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/?id=1b49dc96d103e0151fee290d55cea55aa12c906d).

Even though this is very nice to see fixes and improvements done by people
outside Synopsys IMHO it still makes sense to add SNPS people in the loop so
we may review submitted patches.

So could you please first get an Ack from either Vineet (in Cc) or me before
committing stuff for ARC? Alternatively just Cc 
linux-snps-arc@lists.infradead.org.

Again I'm very happy with uClibc-ng and appreciate a lot all your efforts
and to make uClibc-ng more robust let's review stuff together.

Also it was hard for me to find a relevant patch on the mailing list
because I was expecting patch to be sent via git "send-email" (which I think
should be a standard way for patch submissions in uClibc). Only going through a 
relevant
thread for ARM I found a message with attached files.

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

Re: [PATCH 03/27] drm/arc: Actually bother with handling atomic events.

[Alexey Brodkin]

Hi Daniel,

On Fri, 2016-06-10 at 17:09 +0200, Daniel Vetter wrote:
> On Fri, Jun 10, 2016 at 03:01:03PM +0000, Alexey Brodkin wrote:
> > 
> > > Ok I went ahead and pushed a slight revised version of that patch which
> > > just unconditionally sends out the event. That's not correct, but at least
> > > that way the nonblocking changes won't totally break arcpgu and I can move
> > > ahead with those.
> > Thanks for that.
> > In the meantime I tried previously sent patches:
> > --->8-
> > 9267484 drm/arc: Actually bother with handling atomic events.
> > cf4a489 drm/arc: Nuke event_list
> > 9c3152e drm/atomic-helper: Massage swap_state signature somewhat
> > --->8-
> > and on both boards (axs103 and nSIM OSCI) video works quite fine.
>
> The possible breakage only starts when you move further into the series,
> up to patch 10. That implements generic nonblocking commit, but that
> support relies upon crtc_state->event being signalled. Anyway I'm pulling
> it all into drm-misc now, so you can just test that branch (or linux-next
> when it's rebuild next week).

Ok thanks anyways.
I'll try linux-next once it gets updated with your changes.

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

Re: [PATCH v2 02/20] drm: arc: Rely on the default ->best_encoder() behavior

[Alexey Brodkin]

Hi Boris,

On Tue, 2016-06-07 at 13:47 +0200, Boris Brezillon wrote:
> We have a 1:1 relationship between connectors and encoders and the
> driver is relying on the atomic helpers: we can drop the custom
> ->best_encoder(), and let the core call drm_atomic_helper_best_encoder()
> for us.
> 
> Signed-off-by: Boris Brezillon <boris.brezil...@free-electrons.com>
> ---

Acked-by: Alexey Brodkin <abrod...@synopsys.com>
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: [PATCH 03/27] drm/arc: Actually bother with handling atomic events.

[Alexey Brodkin]

Hi Daniel,

On Fri, 2016-06-10 at 16:54 +0200, Daniel Vetter wrote:
> On Fri, Jun 10, 2016 at 04:19:27PM +0200, Daniel Vetter wrote:
> > 
> > On Fri, Jun 10, 2016 at 01:23:22PM +, Alexey Brodkin wrote:
> > > 
> > > Hi Daniel,
> > > 
> > > On Thu, 2016-06-09 at 16:37 +0200, Daniel Vetter wrote:
> > > > 
> > > > On Thu, Jun 9, 2016 at 4:31 PM, Daniel Vetter <dan...@ffwll.ch> wrote:
> > > > > 
> > > > > 
> > > > > On Thu, Jun 9, 2016 at 4:29 PM, Alexey Brodkin
> > > > > <alexey.brod...@synopsys.com> wrote:
> > > > > > 
> > > > > > 
> > > > > > Hi Daniel,
> > > > > > 
> > > > > > On Thu, 2016-06-09 at 15:52 +0200, Daniel Vetter wrote:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > The fake implementation is fundamentally racy, and I don't want 
> > > > > > > to write
> > > > > > > helpers which can't be used correctly. Anyway I think without 
> > > > > > > this patch
> > > > > > > (or something similar) arcpgu will stall badly with the new 
> > > > > > > nonblocking
> > > > > > > helpers, because arcpgu didn't bother at all to implement 
> > > > > > > nonblocking. Can
> > > > > > > you pls ack this, or even better, test the entire patch series? 
> > > > > > > The
> > > > > > > helpers themselves should work, but in all 5 drivers tested thus 
> > > > > > > far they
> > > > > > > discovered some bugs.
> > > > > > Sure I will happily test this series.
> > > > > > The only question then is what should I use as a proper base?
> > > > > It should apply on drm-next from Dave.
> > > > And indeed it won't work at all because arcpgu doesn't call
> > > > drm_crtc_handle_vblank anywhere. So you need to add your patch to
> > > > enable vblank interrupts somewhere. Note that as long as you leave
> > > > max_vblank_counter as 0, the only bits you need is drm_vblank_init and
> > > > drm_crtc_handle_vblanke() from the irq handler.
> > > So is there any sense in testing that series if vblank interrupt is not 
> > > yet
> > > supported (I'm looking forward to implementing it sometime soon but 
> > > definitely
> > > I'm not there yet)?
> > Well, it might break your driver, so yes. I'm ofc happy to help unbreak it,
> > but without someone who tests there's not much I can do, so will just go
> > ahead and apply and hope it works.
>
> Ok I went ahead and pushed a slight revised version of that patch which
> just unconditionally sends out the event. That's not correct, but at least
> that way the nonblocking changes won't totally break arcpgu and I can move
> ahead with those.

Thanks for that.
In the meantime I tried previously sent patches:
--->8-
9267484 drm/arc: Actually bother with handling atomic events.
cf4a489 drm/arc: Nuke event_list
9c3152e drm/atomic-helper: Massage swap_state signature somewhat
--->8-
and on both boards (axs103 and nSIM OSCI) video works quite fine.

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

[PATCH 3/3 v2] ARC: [nsimosci] Enable ARC PGU on nSIM OSCI virtual platforms

[Alexey Brodkin]

With required ARC PGU updates that allow it to be used on simulation
platforms we may finally utilize ARC PGU in nSIM OSCI virtual platforms
with modern Linux kernels.

Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
---

No changes in v2.

 arch/arc/boot/dts/nsimosci.dts | 14 +++---
 arch/arc/boot/dts/nsimosci_hs.dts  | 14 +++---
 arch/arc/boot/dts/nsimosci_hs_idu.dts  | 14 +++---
 arch/arc/configs/nsimosci_defconfig|  3 ++-
 arch/arc/configs/nsimosci_hs_defconfig |  3 ++-
 arch/arc/configs/nsimosci_hs_smp_defconfig |  3 ++-
 6 files changed, 39 insertions(+), 12 deletions(-)

diff --git a/arch/arc/boot/dts/nsimosci.dts b/arch/arc/boot/dts/nsimosci.dts
index b5b060a..37c416d 100644
--- a/arch/arc/boot/dts/nsimosci.dts
+++ b/arch/arc/boot/dts/nsimosci.dts
@@ -20,7 +20,7 @@
/* this is for console on PGU */
/* bootargs = "console=tty0 consoleblank=0"; */
/* this is for console on serial */
-   bootargs = "earlycon=uart8250,mmio32,0xf000,115200n8 
console=tty0 console=ttyS0,115200n8 consoleblank=0 debug";
+   bootargs = "earlycon=uart8250,mmio32,0xf000,115200n8 
console=tty0 console=ttyS0,115200n8 consoleblank=0 debug video=640x480-24";
};
 
aliases {
@@ -58,9 +58,17 @@
no-loopback-test = <1>;
};
 
-   pgu0: pgu@f900 {
-   compatible = "snps,arcpgufb";
+   pguclk: pguclk {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <25175000>;
+   };
+
+   pgu@f900 {
+   compatible = "snps,arcpgu";
reg = <0xf900 0x400>;
+   clocks = <>;
+   clock-names = "pxlclk";
};
 
ps2: ps2@f9001000 {
diff --git a/arch/arc/boot/dts/nsimosci_hs.dts 
b/arch/arc/boot/dts/nsimosci_hs.dts
index 325e730..f2a22c4 100644
--- a/arch/arc/boot/dts/nsimosci_hs.dts
+++ b/arch/arc/boot/dts/nsimosci_hs.dts
@@ -20,7 +20,7 @@
/* this is for console on PGU */
/* bootargs = "console=tty0 consoleblank=0"; */
/* this is for console on serial */
-   bootargs = "earlycon=uart8250,mmio32,0xf000,115200n8 
console=tty0 console=ttyS0,115200n8 consoleblank=0 debug";
+   bootargs = "earlycon=uart8250,mmio32,0xf000,115200n8 
console=tty0 console=ttyS0,115200n8 consoleblank=0 debug video=640x480-24";
};
 
aliases {
@@ -58,9 +58,17 @@
no-loopback-test = <1>;
};
 
-   pgu0: pgu@f900 {
-   compatible = "snps,arcpgufb";
+   pguclk: pguclk {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <25175000>;
+   };
+
+   pgu@f900 {
+   compatible = "snps,arcpgu";
reg = <0xf900 0x400>;
+   clocks = <>;
+   clock-names = "pxlclk";
};
 
ps2: ps2@f9001000 {
diff --git a/arch/arc/boot/dts/nsimosci_hs_idu.dts 
b/arch/arc/boot/dts/nsimosci_hs_idu.dts
index ee03d71..34457a5 100644
--- a/arch/arc/boot/dts/nsimosci_hs_idu.dts
+++ b/arch/arc/boot/dts/nsimosci_hs_idu.dts
@@ -18,7 +18,7 @@
 
chosen {
/* this is for console on serial */
-   bootargs = "earlycon=uart8250,mmio32,0xf000,115200n8 
console=tty0 console=ttyS0,115200n8 consoleblan=0 debug";
+   bootargs = "earlycon=uart8250,mmio32,0xf000,115200n8 
console=tty0 console=ttyS0,115200n8 consoleblan=0 debug video=640x480-24";
};
 
aliases {
@@ -77,9 +77,17 @@
no-loopback-test = <1>;
};
 
-   pgu0: pgu@f900 {
-   compatible = "snps,arcpgufb";
+   pguclk: pguclk {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <25175000>;
+   };
+
+   pgu@f900 {
+   compatible = "snps,arcpgu";
reg = <0xf900 0x400>;
+   clocks = <>;
+   clock-names = "pxlclk";
};
 
ps2: ps2@f9001000 {
diff --git a/arch/arc/configs/nsimosci_defconfig 
b/arch/arc/configs/nsimosci_defconfig
index

[PATCH 3/3] ARC: [nsimosci] Enable ARC PGU on nSIM OSCI virtual platforms

[Alexey Brodkin]

With required ARC PGU updates that allow it to be used on simulation
platforms we may finally utilize ARC PGU in nSIM OSCI virtual platforms
with modern Linux kernels.

Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
---

No changes in v2.

 arch/arc/boot/dts/nsimosci.dts | 14 +++---
 arch/arc/boot/dts/nsimosci_hs.dts  | 14 +++---
 arch/arc/boot/dts/nsimosci_hs_idu.dts  | 14 +++---
 arch/arc/configs/nsimosci_defconfig|  3 ++-
 arch/arc/configs/nsimosci_hs_defconfig |  3 ++-
 arch/arc/configs/nsimosci_hs_smp_defconfig |  3 ++-
 6 files changed, 39 insertions(+), 12 deletions(-)

diff --git a/arch/arc/boot/dts/nsimosci.dts b/arch/arc/boot/dts/nsimosci.dts
index b5b060a..37c416d 100644
--- a/arch/arc/boot/dts/nsimosci.dts
+++ b/arch/arc/boot/dts/nsimosci.dts
@@ -20,7 +20,7 @@
/* this is for console on PGU */
/* bootargs = "console=tty0 consoleblank=0"; */
/* this is for console on serial */
-   bootargs = "earlycon=uart8250,mmio32,0xf000,115200n8 
console=tty0 console=ttyS0,115200n8 consoleblank=0 debug";
+   bootargs = "earlycon=uart8250,mmio32,0xf000,115200n8 
console=tty0 console=ttyS0,115200n8 consoleblank=0 debug video=640x480-24";
};
 
aliases {
@@ -58,9 +58,17 @@
no-loopback-test = <1>;
};
 
-   pgu0: pgu@f900 {
-   compatible = "snps,arcpgufb";
+   pguclk: pguclk {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <25175000>;
+   };
+
+   pgu@f900 {
+   compatible = "snps,arcpgu";
reg = <0xf900 0x400>;
+   clocks = <>;
+   clock-names = "pxlclk";
};
 
ps2: ps2@f9001000 {
diff --git a/arch/arc/boot/dts/nsimosci_hs.dts 
b/arch/arc/boot/dts/nsimosci_hs.dts
index 325e730..f2a22c4 100644
--- a/arch/arc/boot/dts/nsimosci_hs.dts
+++ b/arch/arc/boot/dts/nsimosci_hs.dts
@@ -20,7 +20,7 @@
/* this is for console on PGU */
/* bootargs = "console=tty0 consoleblank=0"; */
/* this is for console on serial */
-   bootargs = "earlycon=uart8250,mmio32,0xf000,115200n8 
console=tty0 console=ttyS0,115200n8 consoleblank=0 debug";
+   bootargs = "earlycon=uart8250,mmio32,0xf000,115200n8 
console=tty0 console=ttyS0,115200n8 consoleblank=0 debug video=640x480-24";
};
 
aliases {
@@ -58,9 +58,17 @@
no-loopback-test = <1>;
};
 
-   pgu0: pgu@f900 {
-   compatible = "snps,arcpgufb";
+   pguclk: pguclk {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <25175000>;
+   };
+
+   pgu@f900 {
+   compatible = "snps,arcpgu";
reg = <0xf900 0x400>;
+   clocks = <>;
+   clock-names = "pxlclk";
};
 
ps2: ps2@f9001000 {
diff --git a/arch/arc/boot/dts/nsimosci_hs_idu.dts 
b/arch/arc/boot/dts/nsimosci_hs_idu.dts
index ee03d71..34457a5 100644
--- a/arch/arc/boot/dts/nsimosci_hs_idu.dts
+++ b/arch/arc/boot/dts/nsimosci_hs_idu.dts
@@ -18,7 +18,7 @@
 
chosen {
/* this is for console on serial */
-   bootargs = "earlycon=uart8250,mmio32,0xf000,115200n8 
console=tty0 console=ttyS0,115200n8 consoleblan=0 debug";
+   bootargs = "earlycon=uart8250,mmio32,0xf000,115200n8 
console=tty0 console=ttyS0,115200n8 consoleblan=0 debug video=640x480-24";
};
 
aliases {
@@ -77,9 +77,17 @@
no-loopback-test = <1>;
};
 
-   pgu0: pgu@f900 {
-   compatible = "snps,arcpgufb";
+   pguclk: pguclk {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <25175000>;
+   };
+
+   pgu@f900 {
+   compatible = "snps,arcpgu";
reg = <0xf900 0x400>;
+   clocks = <>;
+   clock-names = "pxlclk";
};
 
ps2: ps2@f9001000 {
diff --git a/arch/arc/configs/nsimosci_defconfig 
b/arch/arc/configs/nsimosci_defconfig
index

[PATCH 1/3 v2] drm/arcpgu: Make ARC PGU usable on simulation platforms

[Alexey Brodkin]

From: Ruud Derwig <rder...@synopsys.com>

In case of simulation there's no real encoder/transmitter device
because in the model's virtual LCD  we're rendering whatever
appears in frame-buffer memory.

Signed-off-by: Ruud Derwig <rder...@synopsys.com>
Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
---

Changes v1 -> v2:
 * Got rid of dummy arcpgu_drm_encoder_helper_funcs and now rely on default
   best encoder

 drivers/gpu/drm/arc/Makefile |   2 +-
 drivers/gpu/drm/arc/arcpgu.h |   1 +
 drivers/gpu/drm/arc/arcpgu_drv.c |  15 ++---
 drivers/gpu/drm/arc/arcpgu_sim.c | 128 +++
 4 files changed, 138 insertions(+), 8 deletions(-)
 create mode 100644 drivers/gpu/drm/arc/arcpgu_sim.c

diff --git a/drivers/gpu/drm/arc/Makefile b/drivers/gpu/drm/arc/Makefile
index d48fda7..73de56a 100644
--- a/drivers/gpu/drm/arc/Makefile
+++ b/drivers/gpu/drm/arc/Makefile
@@ -1,2 +1,2 @@
-arcpgu-y := arcpgu_crtc.o arcpgu_hdmi.o arcpgu_drv.o
+arcpgu-y := arcpgu_crtc.o arcpgu_hdmi.o arcpgu_sim.o arcpgu_drv.o
 obj-$(CONFIG_DRM_ARCPGU) += arcpgu.o
diff --git a/drivers/gpu/drm/arc/arcpgu.h b/drivers/gpu/drm/arc/arcpgu.h
index 86574b6..329ac75 100644
--- a/drivers/gpu/drm/arc/arcpgu.h
+++ b/drivers/gpu/drm/arc/arcpgu.h
@@ -43,6 +43,7 @@ static inline u32 arc_pgu_read(struct arcpgu_drm_private 
*arcpgu,
 
 int arc_pgu_setup_crtc(struct drm_device *dev);
 int arcpgu_drm_hdmi_init(struct drm_device *drm, struct device_node *np);
+int arcpgu_drm_sim_init(struct drm_device *drm, struct device_node *np);
 struct drm_fbdev_cma *arcpgu_fbdev_cma_init(struct drm_device *dev,
unsigned int preferred_bpp, unsigned int num_crtc,
unsigned int max_conn_count);
diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index 7675bbc..07c1bde 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -149,15 +149,16 @@ static int arcpgu_load(struct drm_device *drm)
 
/* find the encoder node and initialize it */
encoder_node = of_parse_phandle(drm->dev->of_node, "encoder-slave", 0);
-   if (!encoder_node) {
-   dev_err(drm->dev, "failed to get an encoder slave node\n");
-   return -ENODEV;
+   if (encoder_node) {
+   ret = arcpgu_drm_hdmi_init(drm, encoder_node);
+   if (ret < 0)
+   return ret;
+   } else {
+   ret = arcpgu_drm_sim_init(drm, 0);
+   if (ret < 0)
+   return ret;
}
 
-   ret = arcpgu_drm_hdmi_init(drm, encoder_node);
-   if (ret < 0)
-   return ret;
-
drm_mode_config_reset(drm);
drm_kms_helper_poll_init(drm);
 
diff --git a/drivers/gpu/drm/arc/arcpgu_sim.c b/drivers/gpu/drm/arc/arcpgu_sim.c
new file mode 100644
index 000..2bf06d7
--- /dev/null
+++ b/drivers/gpu/drm/arc/arcpgu_sim.c
@@ -0,0 +1,128 @@
+/*
+ * ARC PGU DRM driver.
+ *
+ * Copyright (C) 2016 Synopsys, Inc. (www.synopsys.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+
+#include "arcpgu.h"
+
+#define XRES_DEF   640
+#define YRES_DEF   480
+
+#define XRES_MAX   8192
+#define YRES_MAX   8192
+
+
+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)
+{
+   int count;
+
+   count = drm_add_modes_noedid(connector, XRES_MAX, YRES_MAX);
+   drm_set_preferred_mode(connector, XRES_DEF, YRES_DEF);
+   return count;
+}
+
+static enum drm_connector_status
+arcpgu_drm_connector_detect(struct drm_connector *connector, bool force)
+{
+   return connector_status_connected;
+}
+
+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 = drm_atomic_helper_connector_duplicate_state,
+   

[PATCH 2/3 v2] ARCv2: [vdk] Enable ARC PGU on HS38 VDK

[Alexey Brodkin]

With required ARC PGU updates that allow it to be used on simulation
platforms we may finally utilize ARC PGU in HS38 VDK with modern
Linux kernels.

Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
---

No changes in v2.

 arch/arc/boot/dts/vdk_axs10x_mb.dtsi| 13 +
 arch/arc/boot/dts/vdk_hs38_smp.dts  |  2 +-
 arch/arc/configs/vdk_hs38_smp_defconfig |  7 ++-
 3 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/arch/arc/boot/dts/vdk_axs10x_mb.dtsi 
b/arch/arc/boot/dts/vdk_axs10x_mb.dtsi
index 45cd665..99498a4 100644
--- a/arch/arc/boot/dts/vdk_axs10x_mb.dtsi
+++ b/arch/arc/boot/dts/vdk_axs10x_mb.dtsi
@@ -23,6 +23,11 @@
#clock-cells = <0>;
};
 
+   pguclk: pguclk {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <25175000>;
+   };
};
 
ethernet@0x18000 {
@@ -75,11 +80,11 @@
};
 
 /* PGU output directly sent to virtual LCD screen; hdmi controller not 
modelled */
-   pgu@0x17000 {
-   compatible = "snps,arcpgufb";
+   pgu@17000 {
+   compatible = "snps,arcpgu";
reg = <0x17000 0x400>;
-   clock-frequency = <5100>; /* PGU'clock is initated 
in init function */
-   /* interrupts = <5>;   PGU interrupts not used, this 
vector is used for ps2 below */
+   clocks = <>;
+   clock-names = "pxlclk";
};
 
 /* VDK has additional ps2 keyboard/mouse interface integrated in LCD screen 
model */
diff --git a/arch/arc/boot/dts/vdk_hs38_smp.dts 
b/arch/arc/boot/dts/vdk_hs38_smp.dts
index 031a5bc..2ba60c39 100644
--- a/arch/arc/boot/dts/vdk_hs38_smp.dts
+++ b/arch/arc/boot/dts/vdk_hs38_smp.dts
@@ -16,6 +16,6 @@
compatible = "snps,axs103";
 
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=640x480-24";
};
 };
diff --git a/arch/arc/configs/vdk_hs38_smp_defconfig 
b/arch/arc/configs/vdk_hs38_smp_defconfig
index 52ec315..969b206 100644
--- a/arch/arc/configs/vdk_hs38_smp_defconfig
+++ b/arch/arc/configs/vdk_hs38_smp_defconfig
@@ -63,12 +63,9 @@ CONFIG_SERIAL_8250_DW=y
 CONFIG_SERIAL_OF_PLATFORM=y
 # CONFIG_HW_RANDOM is not set
 # CONFIG_HWMON is not set
-CONFIG_FB=y
-CONFIG_ARCPGU_RGB888=y
-CONFIG_ARCPGU_DISPTYPE=0
-# CONFIG_VGA_CONSOLE is not set
+CONFIG_DRM=y
+CONFIG_DRM_ARCPGU=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.5.5


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

[PATCH 0/3 v2] Make ARC PGU usable on sim platforms

[Alexey Brodkin]

Initially ARC PGU required real encoder/trnasmitter to exist.
That was fine for real HW such as ARC SDP boards.

But on some simulaiton platroms like ARC VDK or nSIM OSCI we have model
of the same ARC PGU and ability to output video data in a virtual LCD.

To make ARC PGU driver usable in those virtual platforms we need to istantiate
virtual encoder instead of a real one. And that all is done in the first patch
of the series.

Subsequent patches just update configs of both VDK and nSIM OSCI boards
with enabling ARC PGU driver and adding required fixups in their DT
descriptions.

Changes v1 -> v2:
 * Got rid of dummy arcpgu_drm_encoder_helper_funcs and now rely on default
   best encoder

Alexey Brodkin (2):
  ARCv2: [vdk] Enable ARC PGU on HS38 VDK
  ARC: [nsimosci] Enable ARC PGU on nSIM OSCI virtual platforms

Ruud Derwig (1):
  drm/arcpgu: Make ARC PGU usable on simulation platforms

 arch/arc/boot/dts/nsimosci.dts |  14 +++-
 arch/arc/boot/dts/nsimosci_hs.dts  |  14 +++-
 arch/arc/boot/dts/nsimosci_hs_idu.dts  |  14 +++-
 arch/arc/boot/dts/vdk_axs10x_mb.dtsi   |  13 ++-
 arch/arc/boot/dts/vdk_hs38_smp.dts |   2 +-
 arch/arc/configs/nsimosci_defconfig|   3 +-
 arch/arc/configs/nsimosci_hs_defconfig |   3 +-
 arch/arc/configs/nsimosci_hs_smp_defconfig |   3 +-
 arch/arc/configs/vdk_hs38_smp_defconfig|   7 +-
 drivers/gpu/drm/arc/Makefile   |   2 +-
 drivers/gpu/drm/arc/arcpgu.h   |   1 +
 drivers/gpu/drm/arc/arcpgu_drv.c   |  15 ++--
 drivers/gpu/drm/arc/arcpgu_sim.c   | 128 +
 13 files changed, 189 insertions(+), 30 deletions(-)
 create mode 100644 drivers/gpu/drm/arc/arcpgu_sim.c

-- 
2.5.5


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

Re: [PATCH 03/27] drm/arc: Actually bother with handling atomic events.

[Alexey Brodkin]

Hi Daniel,

On Thu, 2016-06-09 at 16:37 +0200, Daniel Vetter wrote:
> On Thu, Jun 9, 2016 at 4:31 PM, Daniel Vetter <dan...@ffwll.ch> wrote:
> > 
> > On Thu, Jun 9, 2016 at 4:29 PM, Alexey Brodkin
> > <alexey.brod...@synopsys.com> wrote:
> > > 
> > > Hi Daniel,
> > > 
> > > On Thu, 2016-06-09 at 15:52 +0200, Daniel Vetter wrote:
> > > > 
> > > > 
> > > > The fake implementation is fundamentally racy, and I don't want to write
> > > > helpers which can't be used correctly. Anyway I think without this patch
> > > > (or something similar) arcpgu will stall badly with the new nonblocking
> > > > helpers, because arcpgu didn't bother at all to implement nonblocking. 
> > > > Can
> > > > you pls ack this, or even better, test the entire patch series? The
> > > > helpers themselves should work, but in all 5 drivers tested thus far 
> > > > they
> > > > discovered some bugs.
> > > Sure I will happily test this series.
> > > The only question then is what should I use as a proper base?
> > It should apply on drm-next from Dave.
>
> And indeed it won't work at all because arcpgu doesn't call
> drm_crtc_handle_vblank anywhere. So you need to add your patch to
> enable vblank interrupts somewhere. Note that as long as you leave
> max_vblank_counter as 0, the only bits you need is drm_vblank_init and
> drm_crtc_handle_vblanke() from the irq handler.

So is there any sense in testing that series if vblank interrupt is not yet
supported (I'm looking forward to implementing it sometime soon but definitely
I'm not there yet)?

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

Re: [PATCH 03/27] drm/arc: Actually bother with handling atomic events.

[Alexey Brodkin]

Hi Daniel,

On Thu, 2016-06-09 at 15:52 +0200, Daniel Vetter wrote:
> 
> The fake implementation is fundamentally racy, and I don't want to write
> helpers which can't be used correctly. Anyway I think without this patch
> (or something similar) arcpgu will stall badly with the new nonblocking
> helpers, because arcpgu didn't bother at all to implement nonblocking. Can
> you pls ack this, or even better, test the entire patch series? The
> helpers themselves should work, but in all 5 drivers tested thus far they
> discovered some bugs.

Sure I will happily test this series.
The only question then is what should I use as a proper base?

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

Re: [PATCH 03/27] drm/arc: Actually bother with handling atomic events.

[Alexey Brodkin]

Hi Daniel,

On Thu, 2016-06-09 at 15:23 +0200, Daniel Vetter wrote:
> On Thu, Jun 09, 2016 at 12:48:31PM +0000, Alexey Brodkin wrote:
> > 
> > Hi Daniel,
> > 
> > On Thu, 2016-06-09 at 14:26 +0200, Daniel Vetter wrote:
> > > 
> > > On Thu, Jun 09, 2016 at 10:54:45AM +, Alexey Brodkin wrote:
> > > > 
> > > > 
> > > > Hi Daniel,
> > > > 
> > > > On Wed, 2016-06-08 at 16:30 +0200, Daniel Vetter wrote:
> > > > > 
> > > > > 
> > > > > On Wed, Jun 08, 2016 at 04:14:38PM +0200, Maarten Lankhorst wrote:
> > > > > > 
> > > > > > 
> > > > > > 
> > > > > > Op 08-06-16 om 14:18 schreef Daniel Vetter:
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > The drm core has a nice ready-made helper for exactly the simple 
> > > > > > > case
> > > > > > > where it should fire on the next vblank.
> > > > > > > 
> > > > > > > Note that arming the vblank event in _begin is probably too 
> > > > > > > early, and
> > > > > > > might easily result in the vblank firing too early, before the 
> > > > > > > new set
> > > > > > > of planes are actually disabled. But that's kinda a minor issue
> > > > > > > compared to just outright hanging userspace.
> > > > > > > 
> > > > > > > v2: Be more robust and either arm, when the CRTC is on, or just 
> > > > > > > send
> > > > > > > the event out right away.
> > > > > > > 
> > > > > > > Cc: Carlos Palminha <palmi...@synopsys.com>
> > > > > > > Cc: Alexey Brodkin <abrod...@synopsys.com>
> > > > > > > Cc: linux-snps-arc@lists.infradead.org
> > > > > > > Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
> > > > > > Wouldn't it be better to do this in atomic_flush then?
> > > > > I'm not going to fix up other people's drivers completely, just 
> > > > > enough to
> > > > > hopefully not break them. If arc also blocks vblank interrupts with 
> > > > > the go
> > > > > bit, then doing this in _begin is correct. Either way it needs 
> > > > > hw-specific
> > > > > knowledge to asses whether it's correct, since doing the vblank event
> > > > > stuff in _flush is also racy without some prevention.
> > > > Actually in ARC PGU driver that was one of many other copy-pastes from
> > > > other drivers. I.e. for me this is another boilerplate and if that's the
> > > > same for other drivers as well probably that's a good candidate for
> > > > generalization into something like drm_helper_crtc_atomic_check().
> > > I checked them all, you are special with your code here. And this can't be
> > > generalized since you must send out vblank events in a race-free manner
> > > against the actual hw update. This requires deep knowledge of the actual
> > > hw, and it's not something the helpers can take care of you. It is very
> > > much not boilerplate, but crucial for a correct implementation. And most
> > > likely arcpgu is wrong, but since I don't have that hw knowledge I'm not
> > > going to change it more than absolutely required.
> > Well I meant as of today we don't support vblank interrupts and so
> > arc_pgu_crtc_atomic_begin() barely makes any sense.
> > 
> > Still in the future we do plan to add support of interrupts.
> 
>
> If you don't support vblank interrupts you're driver isn't compliant with
> atomic. You need to at least fake them.

Indeed. So my assumption was there are (or could appear) other simple drivers
of the same kind and that fake implementation might be generic.

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

Re: [PATCH 03/27] drm/arc: Actually bother with handling atomic events.

[Alexey Brodkin]

Hi Daniel,

On Thu, 2016-06-09 at 14:26 +0200, Daniel Vetter wrote:
> On Thu, Jun 09, 2016 at 10:54:45AM +0000, Alexey Brodkin wrote:
> > 
> > Hi Daniel,
> > 
> > On Wed, 2016-06-08 at 16:30 +0200, Daniel Vetter wrote:
> > > 
> > > On Wed, Jun 08, 2016 at 04:14:38PM +0200, Maarten Lankhorst wrote:
> > > > 
> > > > 
> > > > Op 08-06-16 om 14:18 schreef Daniel Vetter:
> > > > > 
> > > > > 
> > > > > The drm core has a nice ready-made helper for exactly the simple case
> > > > > where it should fire on the next vblank.
> > > > > 
> > > > > Note that arming the vblank event in _begin is probably too early, and
> > > > > might easily result in the vblank firing too early, before the new set
> > > > > of planes are actually disabled. But that's kinda a minor issue
> > > > > compared to just outright hanging userspace.
> > > > > 
> > > > > v2: Be more robust and either arm, when the CRTC is on, or just send
> > > > > the event out right away.
> > > > > 
> > > > > Cc: Carlos Palminha <palmi...@synopsys.com>
> > > > > Cc: Alexey Brodkin <abrod...@synopsys.com>
> > > > > Cc: linux-snps-arc@lists.infradead.org
> > > > > Signed-off-by: Daniel Vetter <daniel.vet...@intel.com>
> > > > Wouldn't it be better to do this in atomic_flush then?
> > > I'm not going to fix up other people's drivers completely, just enough to
> > > hopefully not break them. If arc also blocks vblank interrupts with the go
> > > bit, then doing this in _begin is correct. Either way it needs hw-specific
> > > knowledge to asses whether it's correct, since doing the vblank event
> > > stuff in _flush is also racy without some prevention.
> > Actually in ARC PGU driver that was one of many other copy-pastes from
> > other drivers. I.e. for me this is another boilerplate and if that's the
> > same for other drivers as well probably that's a good candidate for
> > generalization into something like drm_helper_crtc_atomic_check().
>
> I checked them all, you are special with your code here. And this can't be
> generalized since you must send out vblank events in a race-free manner
> against the actual hw update. This requires deep knowledge of the actual
> hw, and it's not something the helpers can take care of you. It is very
> much not boilerplate, but crucial for a correct implementation. And most
> likely arcpgu is wrong, but since I don't have that hw knowledge I'm not
> going to change it more than absolutely required.

Well I meant as of today we don't support vblank interrupts and so
arc_pgu_crtc_atomic_begin() barely makes any sense.

Still in the future we do plan to add support of interrupts.

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

Re: kisskb: FAILED linux-next/axs103_smp_defconfig/arcv2 Thu Jun 09, 17:31

[Alexey Brodkin]

Hi Michael,

On Thu, 2016-06-09 at 14:02 +0530, Vineet Gupta wrote:
> Hi Michael,
> 
> On Thursday 09 June 2016 01:02 PM, nore...@ellerman.id.au wrote:
> > 
> > FAILED linux-next/axs103_smp_defconfig/arcv2 Thu Jun 09, 17:31
> > 
> > http://kisskb.ellerman.id.au/kisskb/buildresult/12713783/
> > 
> > Commit:   Add linux-next specific files for 20160609
> >   8f6027f7e808ed7c1fd8c8d37fc7a5076c683c4f
> > Compiler: arc-buildroot-linux-uclibc-gcc (Buildroot 2015.08.1) 4.8.4
> > 
> > Possible errors
> > ---
> > 
> > {standard input}:18606: Error: Instruction with long immediate data in 
> > delay slot
> > make[2]: *** [block/cfq-iosched.o] Error 1
> > make[1]: *** [block] Error 2
> > make: *** [sub-make] Error 2
> This problem has been fixed in tools since - can you switch to a newer 
> toolchain -
> such as one released last month. @Alexey can you point Michael to right 
> buildroot
> version ?

Unfortunately our most recent tools were released a little bit too late to get 
in
the most recent Buildroot version and so you'll need to build your toolchain
from Buildroot's master branch. Basically everything after the following commit 
will
should work: 
https://git.busybox.net/buildroot/commit/?id=caf515e25e699eb306d0b24986734790de80af28

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

[PATCH 1/3] drm/arcpgu: Make ARC PGU usable on simulation platforms

[Alexey Brodkin]

From: Ruud Derwig <rder...@synopsys.com>

Initially ARC PGU required real encoder/trnasmitter to exist.
That was fine for real HW such as ARC SDP boards.

But on some simulaiton platroms like ARC VDK or nSIM OSCI we have model
of the same ARC PGU and ability to output video data in a virtual LCD.

To make ARC PGU driver usable in those virtual platforms we need to istantiate
virtual encoder instead of a real one because in the model's virtual LCD
we're rendering whatever appears in frame-buffer memory.

Signed-off-by: Ruud Derwig <rder...@synopsys.com>
Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
---
 drivers/gpu/drm/arc/Makefile |   2 +-
 drivers/gpu/drm/arc/arcpgu.h |   1 +
 drivers/gpu/drm/arc/arcpgu_drv.c |  15 ++--
 drivers/gpu/drm/arc/arcpgu_sim.c | 177 +++
 4 files changed, 187 insertions(+), 8 deletions(-)
 create mode 100644 drivers/gpu/drm/arc/arcpgu_sim.c

diff --git a/drivers/gpu/drm/arc/Makefile b/drivers/gpu/drm/arc/Makefile
index d48fda7..73de56a 100644
--- a/drivers/gpu/drm/arc/Makefile
+++ b/drivers/gpu/drm/arc/Makefile
@@ -1,2 +1,2 @@
-arcpgu-y := arcpgu_crtc.o arcpgu_hdmi.o arcpgu_drv.o
+arcpgu-y := arcpgu_crtc.o arcpgu_hdmi.o arcpgu_sim.o arcpgu_drv.o
 obj-$(CONFIG_DRM_ARCPGU) += arcpgu.o
diff --git a/drivers/gpu/drm/arc/arcpgu.h b/drivers/gpu/drm/arc/arcpgu.h
index 86574b6..329ac75 100644
--- a/drivers/gpu/drm/arc/arcpgu.h
+++ b/drivers/gpu/drm/arc/arcpgu.h
@@ -43,6 +43,7 @@ static inline u32 arc_pgu_read(struct arcpgu_drm_private 
*arcpgu,
 
 int arc_pgu_setup_crtc(struct drm_device *dev);
 int arcpgu_drm_hdmi_init(struct drm_device *drm, struct device_node *np);
+int arcpgu_drm_sim_init(struct drm_device *drm, struct device_node *np);
 struct drm_fbdev_cma *arcpgu_fbdev_cma_init(struct drm_device *dev,
unsigned int preferred_bpp, unsigned int num_crtc,
unsigned int max_conn_count);
diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index 69b5be0..5f1f303 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -149,15 +149,16 @@ static int arcpgu_load(struct drm_device *drm)
 
/* find the encoder node and initialize it */
encoder_node = of_parse_phandle(drm->dev->of_node, "encoder-slave", 0);
-   if (!encoder_node) {
-   dev_err(drm->dev, "failed to get an encoder slave node\n");
-   return -ENODEV;
+   if (encoder_node) {
+   ret = arcpgu_drm_hdmi_init(drm, encoder_node);
+   if (ret < 0)
+   return ret;
+   } else {
+   ret = arcpgu_drm_sim_init(drm, 0);
+   if (ret < 0)
+   return ret;
}
 
-   ret = arcpgu_drm_hdmi_init(drm, encoder_node);
-   if (ret < 0)
-   return ret;
-
drm_mode_config_reset(drm);
drm_kms_helper_poll_init(drm);
 
diff --git a/drivers/gpu/drm/arc/arcpgu_sim.c b/drivers/gpu/drm/arc/arcpgu_sim.c
new file mode 100644
index 000..122e069
--- /dev/null
+++ b/drivers/gpu/drm/arc/arcpgu_sim.c
@@ -0,0 +1,177 @@
+/*
+ * ARC PGU DRM driver.
+ *
+ * Copyright (C) 2016 Synopsys, Inc. (www.synopsys.com)
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include 
+#include 
+#include 
+
+#include "arcpgu.h"
+
+#define XRES_DEF   640
+#define YRES_DEF   480
+
+#define XRES_MAX   8192
+#define YRES_MAX   8192
+
+
+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)
+{
+   int count;
+
+   count = drm_add_modes_noedid(connector, XRES_MAX, YRES_MAX);
+   drm_set_preferred_mode(connector, XRES_DEF, YRES_DEF);
+   return count;
+}
+
+static struct drm_encoder *
+arcpgu_drm_connector_best_encoder(struct drm_connector *connector)
+{
+   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_best_encoder: cannot find slave encoder for 
connector\n");
+   return NULL;
+   }
+
+   return >base;
+}
+
+static enum drm_connector_status
+arcpgu_drm_connector_detect(struct drm_connector *connector, bool force)
+{
+   return connect

[PATCH 0/3] Make ARC PGU usable on sim platforms

[Alexey Brodkin]

Initially ARC PGU required real encoder/trnasmitter to exist.
That was fine for real HW such as ARC SDP boards.

But on some simulaiton platroms like ARC VDK or nSIM OSCI we have model
of the same ARC PGU and ability to output video data in a virtual LCD.

To make ARC PGU driver usable in those virtual platforms we need to istantiate
virtual encoder instead of a real one. And that all is done in the first patch
of the series.

Subsequent patches just update configs of both VDK and nSIM OSCI boards
with enabling ARC PGU driver and adding required fixups in their DT
descriptions.

Alexey Brodkin (2):
  ARCv2: [vdk] Enable ARC PGU on HS38 VDK
  ARC: [nsimosci] Enable ARC PGU on nSIM OSCI virtual platforms

Ruud Derwig (1):
  drm/arcpgu: Make ARC PGU usable on simulation platforms

 arch/arc/boot/dts/nsimosci.dts |  14 ++-
 arch/arc/boot/dts/nsimosci_hs.dts  |  14 ++-
 arch/arc/boot/dts/nsimosci_hs_idu.dts  |  14 ++-
 arch/arc/boot/dts/vdk_axs10x_mb.dtsi   |  13 ++-
 arch/arc/boot/dts/vdk_hs38_smp.dts |   2 +-
 arch/arc/configs/nsimosci_defconfig|   3 +-
 arch/arc/configs/nsimosci_hs_defconfig |   3 +-
 arch/arc/configs/nsimosci_hs_smp_defconfig |   3 +-
 arch/arc/configs/vdk_hs38_smp_defconfig|   7 +-
 drivers/gpu/drm/arc/Makefile   |   2 +-
 drivers/gpu/drm/arc/arcpgu.h   |   1 +
 drivers/gpu/drm/arc/arcpgu_drv.c   |  15 +--
 drivers/gpu/drm/arc/arcpgu_sim.c   | 177 +
 13 files changed, 238 insertions(+), 30 deletions(-)
 create mode 100644 drivers/gpu/drm/arc/arcpgu_sim.c

-- 
2.5.5


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

[PATCH 2/3] ARCv2: [vdk] Enable ARC PGU on HS38 VDK

[Alexey Brodkin]

With required ARC PGU updates that allow it to be used on simulation
platforms we may finally utilize ARC PGU in HS38 VDK with modern
Linux kernels.

Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
---
 arch/arc/boot/dts/vdk_axs10x_mb.dtsi| 13 +
 arch/arc/boot/dts/vdk_hs38_smp.dts  |  2 +-
 arch/arc/configs/vdk_hs38_smp_defconfig |  7 ++-
 3 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/arch/arc/boot/dts/vdk_axs10x_mb.dtsi 
b/arch/arc/boot/dts/vdk_axs10x_mb.dtsi
index 45cd665..99498a4 100644
--- a/arch/arc/boot/dts/vdk_axs10x_mb.dtsi
+++ b/arch/arc/boot/dts/vdk_axs10x_mb.dtsi
@@ -23,6 +23,11 @@
#clock-cells = <0>;
};
 
+   pguclk: pguclk {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <25175000>;
+   };
};
 
ethernet@0x18000 {
@@ -75,11 +80,11 @@
};
 
 /* PGU output directly sent to virtual LCD screen; hdmi controller not 
modelled */
-   pgu@0x17000 {
-   compatible = "snps,arcpgufb";
+   pgu@17000 {
+   compatible = "snps,arcpgu";
reg = <0x17000 0x400>;
-   clock-frequency = <5100>; /* PGU'clock is initated 
in init function */
-   /* interrupts = <5>;   PGU interrupts not used, this 
vector is used for ps2 below */
+   clocks = <>;
+   clock-names = "pxlclk";
};
 
 /* VDK has additional ps2 keyboard/mouse interface integrated in LCD screen 
model */
diff --git a/arch/arc/boot/dts/vdk_hs38_smp.dts 
b/arch/arc/boot/dts/vdk_hs38_smp.dts
index 031a5bc..2ba60c39 100644
--- a/arch/arc/boot/dts/vdk_hs38_smp.dts
+++ b/arch/arc/boot/dts/vdk_hs38_smp.dts
@@ -16,6 +16,6 @@
compatible = "snps,axs103";
 
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=640x480-24";
};
 };
diff --git a/arch/arc/configs/vdk_hs38_smp_defconfig 
b/arch/arc/configs/vdk_hs38_smp_defconfig
index 52ec315..969b206 100644
--- a/arch/arc/configs/vdk_hs38_smp_defconfig
+++ b/arch/arc/configs/vdk_hs38_smp_defconfig
@@ -63,12 +63,9 @@ CONFIG_SERIAL_8250_DW=y
 CONFIG_SERIAL_OF_PLATFORM=y
 # CONFIG_HW_RANDOM is not set
 # CONFIG_HWMON is not set
-CONFIG_FB=y
-CONFIG_ARCPGU_RGB888=y
-CONFIG_ARCPGU_DISPTYPE=0
-# CONFIG_VGA_CONSOLE is not set
+CONFIG_DRM=y
+CONFIG_DRM_ARCPGU=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.5.5


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

[PATCH 3/3] ARC: [nsimosci] Enable ARC PGU on nSIM OSCI virtual platforms

[Alexey Brodkin]

With required ARC PGU updates that allow it to be used on simulation
platforms we may finally utilize ARC PGU in nSIM OSCI virtual platforms
with modern Linux kernels.

Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
---
 arch/arc/boot/dts/nsimosci.dts | 14 +++---
 arch/arc/boot/dts/nsimosci_hs.dts  | 14 +++---
 arch/arc/boot/dts/nsimosci_hs_idu.dts  | 14 +++---
 arch/arc/configs/nsimosci_defconfig|  3 ++-
 arch/arc/configs/nsimosci_hs_defconfig |  3 ++-
 arch/arc/configs/nsimosci_hs_smp_defconfig |  3 ++-
 6 files changed, 39 insertions(+), 12 deletions(-)

diff --git a/arch/arc/boot/dts/nsimosci.dts b/arch/arc/boot/dts/nsimosci.dts
index 763d66c..e659a34 100644
--- a/arch/arc/boot/dts/nsimosci.dts
+++ b/arch/arc/boot/dts/nsimosci.dts
@@ -19,7 +19,7 @@
/* this is for console on PGU */
/* bootargs = "console=tty0 consoleblank=0"; */
/* this is for console on serial */
-   bootargs = "earlycon=uart8250,mmio32,0xf000,115200n8 
console=tty0 console=ttyS0,115200n8 consoleblank=0 debug";
+   bootargs = "earlycon=uart8250,mmio32,0xf000,115200n8 
console=tty0 console=ttyS0,115200n8 consoleblank=0 debug video=640x480-24";
};
 
aliases {
@@ -57,9 +57,17 @@
no-loopback-test = <1>;
};
 
-   pgu0: pgu@f900 {
-   compatible = "snps,arcpgufb";
+   pguclk: pguclk {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <25175000>;
+   };
+
+   pgu@f900 {
+   compatible = "snps,arcpgu";
reg = <0xf900 0x400>;
+   clocks = <>;
+   clock-names = "pxlclk";
};
 
ps2: ps2@f9001000 {
diff --git a/arch/arc/boot/dts/nsimosci_hs.dts 
b/arch/arc/boot/dts/nsimosci_hs.dts
index 4eb97c5..16ce5d6 100644
--- a/arch/arc/boot/dts/nsimosci_hs.dts
+++ b/arch/arc/boot/dts/nsimosci_hs.dts
@@ -19,7 +19,7 @@
/* this is for console on PGU */
/* bootargs = "console=tty0 consoleblank=0"; */
/* this is for console on serial */
-   bootargs = "earlycon=uart8250,mmio32,0xf000,115200n8 
console=tty0 console=ttyS0,115200n8 consoleblank=0 debug";
+   bootargs = "earlycon=uart8250,mmio32,0xf000,115200n8 
console=tty0 console=ttyS0,115200n8 consoleblank=0 debug video=640x480-24";
};
 
aliases {
@@ -57,9 +57,17 @@
no-loopback-test = <1>;
};
 
-   pgu0: pgu@f900 {
-   compatible = "snps,arcpgufb";
+   pguclk: pguclk {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <25175000>;
+   };
+
+   pgu@f900 {
+   compatible = "snps,arcpgu";
reg = <0xf900 0x400>;
+   clocks = <>;
+   clock-names = "pxlclk";
};
 
ps2: ps2@f9001000 {
diff --git a/arch/arc/boot/dts/nsimosci_hs_idu.dts 
b/arch/arc/boot/dts/nsimosci_hs_idu.dts
index 853f897..ce8dfbc 100644
--- a/arch/arc/boot/dts/nsimosci_hs_idu.dts
+++ b/arch/arc/boot/dts/nsimosci_hs_idu.dts
@@ -17,7 +17,7 @@
 
chosen {
/* this is for console on serial */
-   bootargs = "earlycon=uart8250,mmio32,0xf000,115200n8 
console=tty0 console=ttyS0,115200n8 consoleblan=0 debug";
+   bootargs = "earlycon=uart8250,mmio32,0xf000,115200n8 
console=tty0 console=ttyS0,115200n8 consoleblan=0 debug video=640x480-24";
};
 
aliases {
@@ -76,9 +76,17 @@
no-loopback-test = <1>;
};
 
-   pgu0: pgu@f900 {
-   compatible = "snps,arcpgufb";
+   pguclk: pguclk {
+   #clock-cells = <0>;
+   compatible = "fixed-clock";
+   clock-frequency = <25175000>;
+   };
+
+   pgu@f900 {
+   compatible = "snps,arcpgu";
reg = <0xf900 0x400>;
+   clocks = <>;
+   clock-names = "pxlclk";
};
 
ps2: ps2@f9001000 {
diff --git a/arch/arc/configs/nsimosci_defconfig 
b/arch/arc/configs/nsimosci_defconfig
index

Re: [PATCH 1/1] net: nps_enet: Disable interrupts before napi reschedule

[Alexey Brodkin]

Hi Elad,

On Thu, 2016-05-26 at 15:00 +0300, Elad Kanfi wrote:
> From: Elad Kanfi <elad...@mellanox.com>
> 
> Since NAPI works by shutting down event interrupts when theres
> work and turning them on when theres none, the net driver must
> make sure that interrupts are disabled when it reschedules polling.
> By calling napi_reschedule, the driver switches to polling mode,
> therefor there should be no interrupt interference.
> Any received packets will be handled in nps_enet_poll by polling the HW
> indication of received packet until all packets are handled.
> 
> Signed-off-by: Elad Kanfi <elad...@mellanox.com>
> Acked-by: Noam Camus <noa...@mellanox.com>
> ---
>  drivers/net/ethernet/ezchip/nps_enet.c |4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/net/ethernet/ezchip/nps_enet.c 
> b/drivers/net/ethernet/ezchip/nps_enet.c
> index 085f912..06f0317 100644
> --- a/drivers/net/ethernet/ezchip/nps_enet.c
> +++ b/drivers/net/ethernet/ezchip/nps_enet.c
> @@ -205,8 +205,10 @@ static int nps_enet_poll(struct napi_struct *napi, int 
> budget)
>    * re-adding ourselves to the poll list.
>    */
>  
> - if (priv->tx_skb && !tx_ctrl_ct)
> + if (priv->tx_skb && !tx_ctrl_ct) {
> + nps_enet_reg_set(priv, NPS_ENET_REG_BUF_INT_ENABLE, 0);
>   napi_reschedule(napi);
> + }
>   }
>  
>   return work_done;

We just bumped into the same problem (data exchange hangs on the very first 
"ping")
with released Linux v4.6 and linux-next on our nSIM OSCI virtual platform.

I believe it was commit 05c00d82f4d1 ("net: nps_enet: bug fix - handle lost tx 
interrupts")
that introduced the problem. At least reverting it I got networking working.

And indeed that patch fixes mentioned issue.
In other words...

Tested-by: Alexey Brodkin <abrod...@synopsys.com>

P.S. Given my observation is correct please add following to your commit
message if you ever do a respin:
-->8---
Fixes: 05c00d82f4d1 ("net: nps_enet: bug fix - handle lost tx interrupts")

Cc: <sta...@vger.kernel.org> # 4.6.x
-->8---
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc

Re: Unaligned flush_dcache_range in axs101.c

[Alexey Brodkin]

Hi Marek,

On Fri, 2016-04-15 at 15:49 +0200, Marek Vasut wrote:
> On 04/15/2016 03:00 PM, Alexey Brodkin wrote:
> > Cache management functions should be implemented per arch or platform and so
> > that they match requirements of underlying hardware. If hardware may only 
> > work on
> > whole cache line then cache routines must do exactly this.
> Is ARC designed this way ?
> 
> > 
> > As an extra options there could be a check for input arguments in those 
> > functions
> > that will warn a user if he or she passes unaligned start and/or end 
> > addresses.
> Right, ARMv7 does it already, ARM926 too, others need fixing.
> 
> > 
> > Now speaking about data layout your example is very correct and we saw a 
> > lot of
> > such real use-cases - developer of drivers should design data layout such 
> > that
> > cache management doesn't lead to data corruption.
> Right.
> 
> > 
> > But again the code in question has nothing to do with cache line.
> > I only need to writeback 1 word and don't care what really happens with
> > all remaining words in the same cache line. And my implementation of
> > flush_dcache_range() will do everything perfectly correct - it will
> > flush exactly 1 line that contains my word I modified.
> And this will lead to silent corruption which is hard to track down and
> debug. I would rather have a check-and-refuse behavior than
> silently-fix-and-permit.

Even though that discussion is still not finished very related issue
actually hit me recently. So it looks like there's more here to discuss and
probably with wider audience.

So what happens: in our newer ARC HS38 cores we may have so-called IO Coherency
block. This hardware block basically makes sure data exchanged between CPU cores
(we may have single-core CPU or multi-core CPU) and DMA masters are coherent.
That means if IOC exists and enabled in the core we:
 1) Don't need to do manual cache management when sending data to peripherals 
and
    getting data back. IOC makes all work for us.
 2) We must not do manual cache management when sending data to peripherals and
    getting data back. Simply because our manual actions will:
    a) Interfere with what IOC already does
    b) Introduce extra performance overhead which we wanted to get rid of with
       invention of IOC.

So with peripherals it is all cool now.
I was just disabling all cache management routines if IOC gets detected on boot.

But returning back to your initial complaint.

In the code you were referring what I wanted to modify reset vector of the 
slave core.
And while we were living without IOC it was all OK. My code above wrote-back
(or as we used to call it within ARC "flushed") L1 data cache with modified
reset vector contents to L2 (which is combined data and instruction cache in 
case of ARC)
and once slave core was unhalted it read reset vector contents via instruction
fetch hardware and executed right what I wanted.

Now with IOC enabled and as I wrote above with disabled cache operations new 
reset
vector value gets stuck in L1 data cache of the master core. And slave cores 
never get
proper value in reset vector effectively going into the wild on unhalt.

The same actually applies to U-Boot relocation and happens even on single-core 
setups.
We copy U-Boot's image to the new location in the memory and until we 
explicitly flush
L1 data cache to the underlying L2 or DDR (if L2 doesn't exist) something may 
not make its
way back to the CPU when it starts fetching instructions from that new location.

So as a summary I would say that we may want to introduce different cache 
handling routines:
 [1] DMA related
 [2] Non-DMA related

Any thoughts? I'm especially interested if something similar happens on other 
arches and
how people deal with it.

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

[PATCH] arc: Get rid of root core-frequency property

[Alexey Brodkin]

Now when we switched to usage of real clk devices for CPU core
frequency those root properties make no sense any longer.
Se we're just getting rid of them here to not confuse readers of
our .dts files.

Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
Cc: Christian Ruppert <christian.rupp...@alitech.com>
Cc: Noam Camus <noa...@mellanox.com>
---
 arch/arc/boot/dts/abilis_tb100.dtsi| 2 --
 arch/arc/boot/dts/abilis_tb101.dtsi| 2 --
 arch/arc/boot/dts/axc001.dtsi  | 1 -
 arch/arc/boot/dts/axc003.dtsi  | 1 -
 arch/arc/boot/dts/axc003_idu.dtsi  | 1 -
 arch/arc/boot/dts/eznps.dts| 1 -
 arch/arc/boot/dts/nsim_700.dts | 1 -
 arch/arc/boot/dts/nsimosci.dts | 1 -
 arch/arc/boot/dts/nsimosci_hs.dts  | 1 -
 arch/arc/boot/dts/nsimosci_hs_idu.dts  | 1 -
 arch/arc/boot/dts/skeleton.dtsi| 1 -
 arch/arc/boot/dts/skeleton_hs.dtsi | 1 -
 arch/arc/boot/dts/skeleton_hs_idu.dtsi | 1 -
 arch/arc/boot/dts/vdk_axc003.dtsi  | 1 -
 arch/arc/boot/dts/vdk_axc003_idu.dtsi  | 1 -
 15 files changed, 17 deletions(-)

diff --git a/arch/arc/boot/dts/abilis_tb100.dtsi 
b/arch/arc/boot/dts/abilis_tb100.dtsi
index 3942634..02410b2 100644
--- a/arch/arc/boot/dts/abilis_tb100.dtsi
+++ b/arch/arc/boot/dts/abilis_tb100.dtsi
@@ -23,8 +23,6 @@
 
 
 / {
-   clock-frequency = <5>;  /* 500 MHZ */
-
soc100 {
bus-frequency   = <1>;
 
diff --git a/arch/arc/boot/dts/abilis_tb101.dtsi 
b/arch/arc/boot/dts/abilis_tb101.dtsi
index b046722..f9e7686 100644
--- a/arch/arc/boot/dts/abilis_tb101.dtsi
+++ b/arch/arc/boot/dts/abilis_tb101.dtsi
@@ -23,8 +23,6 @@
 
 
 / {
-   clock-frequency = <5>;  /* 500 MHZ */
-
soc100 {
bus-frequency   = <1>;
 
diff --git a/arch/arc/boot/dts/axc001.dtsi b/arch/arc/boot/dts/axc001.dtsi
index 3e02f15..6ae2c47 100644
--- a/arch/arc/boot/dts/axc001.dtsi
+++ b/arch/arc/boot/dts/axc001.dtsi
@@ -15,7 +15,6 @@
 
 / {
compatible = "snps,arc";
-   clock-frequency = <75000>;  /* 750 MHZ */
#address-cells = <1>;
#size-cells = <1>;
 
diff --git a/arch/arc/boot/dts/axc003.dtsi b/arch/arc/boot/dts/axc003.dtsi
index 378e455..14df46f 100644
--- a/arch/arc/boot/dts/axc003.dtsi
+++ b/arch/arc/boot/dts/axc003.dtsi
@@ -14,7 +14,6 @@
 
 / {
compatible = "snps,arc";
-   clock-frequency = <9000>;
#address-cells = <1>;
#size-cells = <1>;
 
diff --git a/arch/arc/boot/dts/axc003_idu.dtsi 
b/arch/arc/boot/dts/axc003_idu.dtsi
index 64c94b2..3d6cfa3 100644
--- a/arch/arc/boot/dts/axc003_idu.dtsi
+++ b/arch/arc/boot/dts/axc003_idu.dtsi
@@ -14,7 +14,6 @@
 
 / {
compatible = "snps,arc";
-   clock-frequency = <9000>;
#address-cells = <1>;
#size-cells = <1>;
 
diff --git a/arch/arc/boot/dts/eznps.dts b/arch/arc/boot/dts/eznps.dts
index b89f6c3..1e0d225 100644
--- a/arch/arc/boot/dts/eznps.dts
+++ b/arch/arc/boot/dts/eznps.dts
@@ -18,7 +18,6 @@
 
 / {
compatible = "ezchip,arc-nps";
-   clock-frequency = <8333>;   /* 83.33 MHZ */
#address-cells = <1>;
#size-cells = <1>;
interrupt-parent = <>;
diff --git a/arch/arc/boot/dts/nsim_700.dts b/arch/arc/boot/dts/nsim_700.dts
index 5d5e373..6397051 100644
--- a/arch/arc/boot/dts/nsim_700.dts
+++ b/arch/arc/boot/dts/nsim_700.dts
@@ -11,7 +11,6 @@
 
 / {
compatible = "snps,nsim";
-   clock-frequency = <8000>;   /* 80 MHZ */
#address-cells = <1>;
#size-cells = <1>;
interrupt-parent = <_intc>;
diff --git a/arch/arc/boot/dts/nsimosci.dts b/arch/arc/boot/dts/nsimosci.dts
index b5b060a..763d66c 100644
--- a/arch/arc/boot/dts/nsimosci.dts
+++ b/arch/arc/boot/dts/nsimosci.dts
@@ -11,7 +11,6 @@
 
 / {
compatible = "snps,nsimosci";
-   clock-frequency = <2000>;   /* 20 MHZ */
#address-cells = <1>;
#size-cells = <1>;
interrupt-parent = <_intc>;
diff --git a/arch/arc/boot/dts/nsimosci_hs.dts 
b/arch/arc/boot/dts/nsimosci_hs.dts
index 325e730..4eb97c5 100644
--- a/arch/arc/boot/dts/nsimosci_hs.dts
+++ b/arch/arc/boot/dts/nsimosci_hs.dts
@@ -11,7 +11,6 @@
 
 / {
compatible = "snps,nsimosci_hs";
-   clock-frequency = <2000>;   /* 20 MHZ */
#address-cells = <1>;
#size-cells = <1>;
interrupt-parent = <_intc>;
diff --git a/arch/arc/boot/dts/nsimosci_hs_idu.dts 
b/arch/arc/boot/dts/nsimosci_hs_idu.dts
index ee03d71..853f897 100644
--- a/arch/arc/boot/dts/nsimosci_hs_idu.dts
+++ b/arch/arc/boot/dts/nsimosci_hs_idu.dts
@@ -11,7 +11,6 @@
 
 / {
compatible = "snps,nsimosci_hs";
-   clock-frequency = <500>;/* 5 MHZ */

Re: [GIT PULL] drm/arcpgu: use dedicated memory area for frame buffer

[Alexey Brodkin]

Hi David,

On Mon, 2016-05-23 at 15:23 -0400, David Airlie wrote:
> 
> 
> - Original Message -
> > 
> > From: "Alexey Brodkin" <alexey.brod...@synopsys.com>
> > To: airl...@redhat.com, dan...@ffwll.ch, "Vineet Gupta" 
> > <vineet.gup...@synopsys.com>, airl...@linux.ie
> > Cc: dri-de...@lists.freedesktop.org, linux-ker...@vger.kernel.org, 
> > linux-snps-arc@lists.infradead.org
> > Sent: Monday, 23 May, 2016 8:31:41 PM
> > Subject: Re: [GIT PULL] drm/arcpgu: use dedicated memory area for frame 
> > buffer
> > 
> > Alternatively you may just apply the first patch from the series
> > (could be found here
> >  https://lists.freedesktop.org/archives/dri-devel/2016-April/106280.html)
> > and the second patch will be picked up by ARC maintainer (Vineet Gupta).
> I thought I did pull this, please check drm-next.

Oops. Indeed it's in linux-next.
Sorry for that noise. Will double-check linux-next next time before bugging 
people.

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

[PATCH] ldso: Force disable -mlong-calls when compiling ldso for ARC

[Alexey Brodkin]

Even though by default for ARC uClibc gets compiled with
disabled long-calls user may provide UCLIBC_EXTRA_CFLAGS
with "-mlong-calls". With this option uClibc will be
successfully compiled but later it will fail in runtime
because dynamic loader cannot deal with relocations
at least very early on its start.

In particular it will be seen as call to non-relocated
symbol _dl_parse_dynamic_info() which ends-up as a segfault
like this:
>8
potentially unexpected fatal signal 11.
Path: /bin/test
CPU: 0 PID: 63 Comm: test Not tainted 4.5.2 #7
task: 9f13f180 ti: 9f166000 task.ti: 9f166000

[ECR   ]: 0x0004 => Insn could not be fetched
[EFA   ]: 0x283c
[BLINK ]: 0x2000407c
[ERET  ]: 0x283c
@No matching VMA found
[STAT32]: 0x8008009e : IE U
BTA: 0x283c  SP: 0x5fef5ccc  FP: 0x
LPS: 0x20004080 LPE: 0x20004064 LPC: 0x
r00: 0x20006684 r01: 0x5fef5db0 r02: 0x
r03: 0x2000 r04: 0x80808080 r05: 0x2f2f2f2f
r06: 0x41464d00 r07: 0x0080 r08: 0x00dd
r09: 0x r10: 0x0073 r11: 0x80808080
r12: 0x2000407c r13: 0x2000 r14: 0x5fef5e74
r15: 0x000ceb3c r16: 0x5fef5e7c r17: 0x5fef5d44
r18: 0x000ceb0c r19: 0x r20: 0x000ceb1c
r21: 0x r22: 0x r23: 0x000d08a5
r24: 0x r25: 0x80808080

Segmentation fault
>8

Solution to this issue is simple we make sure dynamic
loader never gets compiled with "-mlong-calls" by forcing
"-mno-long-calls" on it.

Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
Cc: Vineet Gupta <vgu...@synopsys.com>
Cc: Anton Kolesov <akole...@synopsys.com>
Cc: linux-snps-arc@lists.infradead.org
---
 ldso/ldso/Makefile.in | 4 
 1 file changed, 4 insertions(+)

diff --git a/ldso/ldso/Makefile.in b/ldso/ldso/Makefile.in
index d85646a..dde6a53 100644
--- a/ldso/ldso/Makefile.in
+++ b/ldso/ldso/Makefile.in
@@ -34,6 +34,10 @@ CFLAGS-$(DODEBUG)-ldso/ldso := -O2 -g
 
 CFLAGS-ldso.c := -DLDSO_ELFINTERP=\"$(TARGET_ARCH)/elfinterp.c\"
 
+ifeq ($(TARGET_ARCH),arc)
+CFLAGS-ldso.c += -mno-long-calls
+endif
+
 LDFLAGS-$(UCLIBC_FORMAT_DSBT_ELF)-$(UCLIBC_LDSO_NAME).so := -Wl,--dsbt-index=1
 ifneq ($(SUPPORT_LD_DEBUG),y)
 LDFLAGS-$(UCLIBC_LDSO_NAME).so := $(LDFLAGS)
-- 
2.5.5


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

Re: [GIT PULL] drm/arcpgu: use dedicated memory area for frame buffer

[Alexey Brodkin]

Hi Dave,

On Mon, 2016-05-16 at 08:22 +, Alexey Brodkin wrote:
> Hi Dave,
> 
> On Tue, 2016-05-10 at 09:51 +0000, Alexey Brodkin wrote:
> > 
> > Hi Dave,
> > 
> > On Fri, 2016-04-29 at 11:36 +, Alexey Brodkin wrote:
> > > 
> > > 
> > > Hi Dave,
> > > 
> > > Please pull this mini-series that allows ARC PGU to use
> > > dedicated memory location as framebuffer backing storage.
> > > 
> > > v2 of that series was reviewed here
> > > https://lists.freedesktop.org/archives/dri-devel/2016-April/106279.html
> > > 
> > > It is based on top of today's drm-next branch.
> > > 
> > > Best regards,
> > > Alexey
> > > 
> > > The following changes since commit 
> > > b89359bdf0f1e95a4c5f92300594ba9dde323fc4:
> > > 
> > >   Merge branch 'for-next' of http://git.agner.ch/git/linux-drm-fsl-dcu 
> > > into drm-next (2016-04-29 14:57:51 +1000)
> > > 
> > > are available in the git repository at:
> > > 
> > >   https://github.com/foss-for-synopsys-dwc-arc-processors/linux.git 
> > > topic-arcpgu-updates
> > > 
> > > for you to fetch changes up to cb2ad5e5339c5122166265cea579cc6a356d46de:
> > > 
> > >   ARC: [axs10x] Specify reserved memory for frame buffer (2016-04-29 
> > > 14:34:13 +0300)
> > > 
> > > 
> > > Alexey Brodkin (2):
> > >   drm/arcpgu: use dedicated memory area for frame buffer
> > >   ARC: [axs10x] Specify reserved memory for frame buffer
> > > 
> > >  arch/arc/boot/dts/axc001.dtsi | 22 --
> > >  arch/arc/boot/dts/axc003.dtsi | 14 ++
> > >  arch/arc/boot/dts/axc003_idu.dtsi | 14 ++
> > >  arch/arc/boot/dts/axs10x_mb.dtsi  |  2 +-
> > >  drivers/gpu/drm/arc/arcpgu_drv.c  |  6 ++
> > >  5 files changed, 55 insertions(+), 3 deletions(-)
> > Could you please take a look at this pull request?
> Another polite reminder.

Could you please pull this one?
Indeed it was created quite some time ago so if required I may
rebase it on top of whatever current you'd like.

Alternatively you may just apply the first patch from the series
(could be found here 
https://lists.freedesktop.org/archives/dri-devel/2016-April/106280.html)
and the second patch will be picked up by ARC maintainer (Vineet Gupta).

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

[PATCH] arc: axs103_smp: Fix CPU frequency to 100MHz for dual-core

[Alexey Brodkin]

The most recent release of AXS103 [v1.1] is proven to work
at 100 MHz in dual-core mode so this change uses mentioned feature.
For that we:
 * Update axc003_idu.dtsi with mention of really-used CPU clock freq
 * Remove clock override in AXS platform code for dual-core HW

Note we're still leaving a hack for clock "downgrade" on early boot
for quad-core hardware.

Also note this change will break functionality of AXS103 v1.0 hardware.
That means all users of AXS103 __must__ upgrade their boards with the
most recent firmware.

Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
---
 arch/arc/boot/dts/axc003_idu.dtsi | 2 +-
 arch/arc/plat-axs10x/axs10x.c | 2 --
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/arch/arc/boot/dts/axc003_idu.dtsi 
b/arch/arc/boot/dts/axc003_idu.dtsi
index 8955881d..ed1674b 100644
--- a/arch/arc/boot/dts/axc003_idu.dtsi
+++ b/arch/arc/boot/dts/axc003_idu.dtsi
@@ -28,7 +28,7 @@
core_clk: core_clk {
#clock-cells = <0>;
compatible = "fixed-clock";
-   clock-frequency = <9000>;
+   clock-frequency = <1>;
};
 
core_intc: archs-intc@cpu {
diff --git a/arch/arc/plat-axs10x/axs10x.c b/arch/arc/plat-axs10x/axs10x.c
index 9701c93..8654870 100644
--- a/arch/arc/plat-axs10x/axs10x.c
+++ b/arch/arc/plat-axs10x/axs10x.c
@@ -410,8 +410,6 @@ static void __init axs103_early_init(void)
unsigned int num_cores = (read_aux_reg(ARC_REG_MCIP_BCR) >> 16) & 0x3F;
if (num_cores > 2)
freq = 50;
-   else if (num_cores == 2)
-   freq = 75;
 #endif
 
switch (freq) {
-- 
2.5.5


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

Re: [PATCH 2/2] ARC: [axs10x] Specify reserved memory for frame buffer

[Alexey Brodkin]

Hi Vineet,

On Thu, 2016-04-28 at 19:26 +0530, Vineet Gupta wrote:
> On Thursday 28 April 2016 07:16 PM, Alexey Brodkin wrote:
> > 
> > > 
> > > > 
> > > > Note that the IOC start alignment needs to follow
> > > > max(4k, size). What will be maximum size of frame buffer - 16M always !
> > What do you mean by that?
> For HS38, we intend to bypass the frame buffer traffic from IOC port. So the 
> frame
> buffer start needs to be inside the IOC aperture base address. That value 
> can't be
> arbitrary - it is atleast 4K aligned value and further also needs to be 
> aligned to
> the size of aperture. So if the size is 16M it needs to be 16M aligned etc...

The point is we want to put frame buffer memory OUTSIDE IOC aperture.
So we allocate FB memory in the very end of DDR which is far away from IOC.

And in that case IOC alignment issues are out of the question here.

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

[PATCH 1/2 v2] drm/arcpgu: use dedicated memory area for frame buffer

[Alexey Brodkin]

Now when ARC supports reserved memory areas and
per-device coherent DMA allocations we may switch ARC PGU
to use of those dedicated areas.

One of the benefits we may move frame-buffer area out
from IO Coherency aperture and so significantly
reduce IOC utilization allowing less demanding
peripherals to use all perks of IOC.

Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
Cc: Dave Airlie <airl...@gmail.com>
Cc: Daniel Vetter <dan...@ffwll.ch>
---

No changes v1 -> v2.

 drivers/gpu/drm/arc/arcpgu_drv.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/arc/arcpgu_drv.c b/drivers/gpu/drm/arc/arcpgu_drv.c
index 5b35e5db..76e187a 100644
--- a/drivers/gpu/drm/arc/arcpgu_drv.c
+++ b/drivers/gpu/drm/arc/arcpgu_drv.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "arcpgu.h"
 #include "arcpgu_regs.h"
@@ -135,6 +136,11 @@ static int arcpgu_load(struct drm_device *drm)
dev_info(drm->dev, "arc_pgu ID: 0x%x\n",
 arc_pgu_read(arcpgu, ARCPGU_REG_ID));
 
+   /* Get the optional framebuffer memory resource */
+   ret = of_reserved_mem_device_init(drm->dev);
+   if (ret && ret != -ENODEV)
+   return ret;
+
if (dma_set_mask_and_coherent(drm->dev, DMA_BIT_MASK(32)))
return -ENODEV;
 
-- 
2.5.5


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

Re: [PATCH 2/2] ARC: [axs10x] Specify reserved memory for frame buffer

[Alexey Brodkin]

Hi Vineet,

On Thu, 2016-04-28 at 09:56 +0530, Vineet Gupta wrote:

[snip]

> > 
> > diff --git a/arch/arc/boot/dts/axc001.dtsi b/arch/arc/boot/dts/axc001.dtsi
> > index 420dcfd..ae6162d 100644
> > --- a/arch/arc/boot/dts/axc001.dtsi
> > +++ b/arch/arc/boot/dts/axc001.dtsi
> > @@ -95,6 +95,24 @@
> >     #size-cells = <1>;
> >     ranges = <0x 0x8000 0x4000>;
> >     device_type = "memory";
> > -   reg = <0x8000 0x2000>;  /* 512MiB */
> > +   reg = <0x8000 0x1f00>;  /* 512 - 16 MiB */
> Is 16MB fixed size or is this a function of display resolution / density etc.

Indeed this value depends on screen resolution and bpp and double-
or even tripple-buffering (once this becomes supported in the driver).

So as of now the corner case would be 1920x1080, 16 bits per pixel
which gives ~4Mb. Now if we add support of triple-buffering we'll
need ~12Mb so I booked a little bit more - 16Mb.

But now I recalled that we also support r8g8b8 mode and in this case
3 bytes are used for color encoding, which effectively gives ~6Mb for
1 FullHD frame. And for tripple-buffering we'll need > 18Mb, so probably
we'll need to go for 24 or even 32 Mb.

[snip]

> > +
> > +   reserved-memory {
> > +   #address-cells = <1>;
> > +   #size-cells = <1>;
> > +   ranges;
> > +   /*
> > +    * Move frame buffer out of IOC aperture (0x8z-0xAz).
> > +    */
> > +   frame_buffer: frame_buffer@bf00 {
> > +   compatible = "shared-dma-pool";
> > +   reg = <0xbf00 0x100>;
> Can this be made a bit more future safe. AXS103 has 1 GB of DDR while kernel
> currently only uses 512M. Once we increase that, this will need fixing too. 
> Better
> to make this as far possible.

Makes sense. Will move it to the very end of 1Gb.

> Note that the IOC start alignment needs to follow
> max(4k, size). What will be maximum size of frame buffer - 16M always !

What do you mean by that?

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

[PATCH 2/2] ARC: [axs10x] Specify reserved memory for frame buffer

[Alexey Brodkin]

Allocation of a frame buffer memory in a special memory region
allows bypassing of so-called IO Coherency aperture
which is typically set as a range 0x8z-0xAz.

I.e. all data traffic to PGU bypasses IO Coherency block
and saves its bandwidth for other peripherals.

Even though for AXS101 (which sorts ARC770 CPU) IOC is not
an option for a sake of keeping one DT description for the
base-board (axs10x_mb.dtsi) we're still defining reserved
memory location in the very end of DDR.

Signed-off-by: Alexey Brodkin <abrod...@synopsys.com>
Cc: devicet...@vger.kernel.org
---
 arch/arc/boot/dts/axc001.dtsi | 20 +++-
 arch/arc/boot/dts/axc003.dtsi | 14 ++
 arch/arc/boot/dts/axc003_idu.dtsi | 14 ++
 arch/arc/boot/dts/axs10x_mb.dtsi  |  2 +-
 4 files changed, 48 insertions(+), 2 deletions(-)

diff --git a/arch/arc/boot/dts/axc001.dtsi b/arch/arc/boot/dts/axc001.dtsi
index 420dcfd..ae6162d 100644
--- a/arch/arc/boot/dts/axc001.dtsi
+++ b/arch/arc/boot/dts/axc001.dtsi
@@ -95,6 +95,24 @@
#size-cells = <1>;
ranges = <0x 0x8000 0x4000>;
device_type = "memory";
-   reg = <0x8000 0x2000>;  /* 512MiB */
+   reg = <0x8000 0x1f00>;  /* 512 - 16 MiB */
+   };
+
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+   /*
+* We just move frame buffer area to the very end of
+* available DDR. And even though in case of ARC770 there's
+* no strict requirement for a frame-buffer to be in any
+* particular location it allows us to use the same
+* base board's DT node for ARC PGU as for ARc HS38.
+*/
+   frame_buffer: frame_buffer@9f00 {
+   compatible = "shared-dma-pool";
+   reg = <0x9f00 0x100>;
+   no-map;
+   };
};
 };
diff --git a/arch/arc/boot/dts/axc003.dtsi b/arch/arc/boot/dts/axc003.dtsi
index f90fadf..c7a95c2 100644
--- a/arch/arc/boot/dts/axc003.dtsi
+++ b/arch/arc/boot/dts/axc003.dtsi
@@ -100,4 +100,18 @@
device_type = "memory";
reg = <0x8000 0x2000>;  /* 512MiB */
};
+
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+   /*
+* Move frame buffer out of IOC aperture (0x8z-0xAz).
+*/
+   frame_buffer: frame_buffer@a000 {
+   compatible = "shared-dma-pool";
+   reg = <0xa000 0x100>;
+   no-map;
+   };
+   };
 };
diff --git a/arch/arc/boot/dts/axc003_idu.dtsi 
b/arch/arc/boot/dts/axc003_idu.dtsi
index 06a9f29..929ec8c 100644
--- a/arch/arc/boot/dts/axc003_idu.dtsi
+++ b/arch/arc/boot/dts/axc003_idu.dtsi
@@ -123,4 +123,18 @@
device_type = "memory";
reg = <0x8000 0x2000>;  /* 512MiB */
};
+
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+   /*
+* Move frame buffer out of IOC aperture (0x8z-0xAz).
+*/
+   frame_buffer: frame_buffer@a000 {
+   compatible = "shared-dma-pool";
+   reg = <0xa000 0x100>;
+   no-map;
+   };
+   };
 };
diff --git a/arch/arc/boot/dts/axs10x_mb.dtsi b/arch/arc/boot/dts/axs10x_mb.dtsi
index 823f15c..64b063d 100644
--- a/arch/arc/boot/dts/axs10x_mb.dtsi
+++ b/arch/arc/boot/dts/axs10x_mb.dtsi
@@ -283,7 +283,7 @@
encoder-slave = <>;
clocks = <>;
clock-names = "pxlclk";
-
+   memory-region = <_buffer>;
port {
pgu_output: endpoint {
remote-endpoint = <_input>;
-- 
2.5.5


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

[PATCH 0/2] drm/arcpgu: Get use of dedicated memory area for frame buffer

[Alexey Brodkin]

This mini-series allows to allocate frame buffer memory in desired
location. Allocation of a frame buffer memory in a special memory region
allows bypassing of so-called IO Coherency aperture which is typically set
as a range 0x8z-0xAz.

I.e. all data traffic to PGU bypasses IO Coherency block
and saves its bandwidth for other peripherals.

Cc: Cc: Dave Airlie <airl...@gmail.com>
Cc: Daniel Vetter <dan...@ffwll.ch>
Cc: devicet...@vger.kernel.org

Alexey Brodkin (2):
  drm/arcpgu: use dedicated memory area for frame buffer
  ARC: [axs10x] Specify reserved memory for frame buffer

 arch/arc/boot/dts/axc001.dtsi | 20 +++-
 arch/arc/boot/dts/axc003.dtsi | 14 ++
 arch/arc/boot/dts/axc003_idu.dtsi | 14 ++
 arch/arc/boot/dts/axs10x_mb.dtsi  |  2 +-
 drivers/gpu/drm/arc/arcpgu_drv.c  |  6 ++
 5 files changed, 54 insertions(+), 2 deletions(-)

-- 
2.5.5


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