<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/include/soc, branch linux-4.17.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-4.17.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-4.17.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2018-08-03T05:47:58Z</updated>
<entry>
<title>memory: tegra: Apply interrupts mask per SoC</title>
<updated>2018-08-03T05:47:58Z</updated>
<author>
<name>Dmitry Osipenko</name>
<email>digetx@gmail.com</email>
</author>
<published>2018-04-09T19:28:29Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=bce56f0cb64a1e0a461e1aba39c666958d5aaa40'/>
<id>urn:sha1:bce56f0cb64a1e0a461e1aba39c666958d5aaa40</id>
<content type='text'>
[ Upstream commit 1c74d5c0de0c2cc29fef97a19251da2ad6f579bd ]

Currently we are enabling handling of interrupts specific to Tegra124+
which happen to overlap with previous generations. Let's specify
interrupts mask per SoC generation for consistency and in a preparation
of squashing of Tegra20 driver into the common one that will enable
handling of GART faults which may be undesirable by newer generations.

Signed-off-by: Dmitry Osipenko &lt;digetx@gmail.com&gt;
Signed-off-by: Thierry Reding &lt;treding@nvidia.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>soc: bcm2835: Make !RASPBERRYPI_FIRMWARE dummies return failure</title>
<updated>2018-04-16T22:15:23Z</updated>
<author>
<name>Geert Uytterhoeven</name>
<email>geert@linux-m68k.org</email>
</author>
<published>2018-04-08T09:05:15Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=144345a4a8c3b497a3f60d3af9d6071a37660186'/>
<id>urn:sha1:144345a4a8c3b497a3f60d3af9d6071a37660186</id>
<content type='text'>
If CONFIG_RASPBERRYPI_FIRMWARE=n:

    drivers/gpio/gpio-raspberrypi-exp.c: In function ‘rpi_exp_gpio_get_polarity’:
    drivers/gpio/gpio-raspberrypi-exp.c:71: warning: ‘get.polarity’ is used uninitialized in this function
    drivers/gpio/gpio-raspberrypi-exp.c: In function ‘rpi_exp_gpio_get_direction’:
    drivers/gpio/gpio-raspberrypi-exp.c:150: warning: ‘get.direction’ is used uninitialized in this function

The dummy firmware interface functions return 0, which means success,
causing subsequent code to make use of the never initialized output
parameter.

Fix this by making the dummy functions return an error code (-ENOSYS)
instead.

Note that this assumes the firmware always fills in the requested data
in the CONFIG_RASPBERRYPI_FIRMWARE=y case.

Fixes: d45f1a563b92dac7 ("staging: vc04_services: fix up rpi firmware functions")
Signed-off-by: Geert Uytterhoeven &lt;geert@linux-m68k.org&gt;
Reviewed-by: Eric Anholt &lt;eric@anholt.net&gt;
Signed-off-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc</title>
<updated>2018-04-06T04:29:35Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2018-04-06T04:29:35Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=38c23685b273cfb4ccf31a199feccce3bdcb5d83'/>
<id>urn:sha1:38c23685b273cfb4ccf31a199feccce3bdcb5d83</id>
<content type='text'>
Pull ARM SoC driver updates from Arnd Bergmann:
 "The main addition this time around is the new ARM "SCMI" framework,
  which is the latest in a series of standards coming from ARM to do
  power management in a platform independent way.

  This has been through many review cycles, and it relies on a rather
  interesting way of using the mailbox subsystem, but in the end I
  agreed that Sudeep's version was the best we could do after all.

  Other changes include:

   - the ARM CCN driver is moved out of drivers/bus into drivers/perf,
     which makes more sense. Similarly, the performance monitoring
     portion of the CCI driver are moved the same way and cleaned up a
     little more.

   - a series of updates to the SCPI framework

   - support for the Mediatek mt7623a SoC in drivers/soc

   - support for additional NVIDIA Tegra hardware in drivers/soc

   - a new reset driver for Socionext Uniphier

   - lesser bug fixes in drivers/soc, drivers/tee, drivers/memory, and
     drivers/firmware and drivers/reset across platforms"

* tag 'armsoc-drivers' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (87 commits)
  reset: uniphier: add ethernet reset control support for PXs3
  reset: stm32mp1: Enable stm32mp1 reset driver
  dt-bindings: reset: add STM32MP1 resets
  reset: uniphier: add Pro4/Pro5/PXs2 audio systems reset control
  reset: imx7: add 'depends on HAS_IOMEM' to fix unmet dependency
  reset: modify the way reset lookup works for board files
  reset: add support for non-DT systems
  clk: scmi: use devm_of_clk_add_hw_provider() API and drop scmi_clocks_remove
  firmware: arm_scmi: prevent accessing rate_discrete uninitialized
  hwmon: (scmi) return -EINVAL when sensor information is unavailable
  amlogic: meson-gx-socinfo: Update soc ids
  soc/tegra: pmc: Use the new reset APIs to manage reset controllers
  soc: mediatek: update power domain data of MT2712
  dt-bindings: soc: update MT2712 power dt-bindings
  cpufreq: scmi: add thermal dependency
  soc: mediatek: fix the mistaken pointer accessed when subdomains are added
  soc: mediatek: add SCPSYS power domain driver for MediaTek MT7623A SoC
  soc: mediatek: avoid hardcoded value with bus_prot_mask
  dt-bindings: soc: add header files required for MT7623A SCPSYS dt-binding
  dt-bindings: soc: add SCPSYS binding for MT7623 and MT7623A SoC
  ...
</content>
</entry>
<entry>
<title>Merge tag 'tegra-for-4.17-firmware' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/tegra/linux into next/drivers</title>
<updated>2018-03-27T13:50:57Z</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2018-03-27T13:50:57Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=d0994465d0eaeab1627697d88eccfa32bbd39714'/>
<id>urn:sha1:d0994465d0eaeab1627697d88eccfa32bbd39714</id>
<content type='text'>
Pull "firmware: Changes for v4.17-rc1" from Thierry Reding:

These changes are rather small, with just a fix for a return value check
and some preparatory work for Tegra194 BPMP support.

* tag 'tegra-for-4.17-firmware' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
  firmware: tegra: adjust tested variable
  firmware: tegra: Simplify channel management
</content>
</entry>
<entry>
<title>Merge tag 'v4.16-rc5' into devel</title>
<updated>2018-03-18T16:48:59Z</updated>
<author>
<name>Linus Walleij</name>
<email>linus.walleij@linaro.org</email>
</author>
<published>2018-03-18T16:48:59Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=95260c17b27e4bdacf85022e629fb701b42cc190'/>
<id>urn:sha1:95260c17b27e4bdacf85022e629fb701b42cc190</id>
<content type='text'>
Linux 4.16-rc5 merged into the GPIO devel branch to resolve
a nasty conflict between fixes and devel in the RCAR driver.

Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
</content>
</entry>
<entry>
<title>firmware: tegra: Simplify channel management</title>
<updated>2018-03-08T13:20:58Z</updated>
<author>
<name>Mikko Perttunen</name>
<email>mperttunen@nvidia.com</email>
</author>
<published>2018-02-20T11:58:06Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=1abb081e41a718d73183b0e1b76bfff66e92f7e1'/>
<id>urn:sha1:1abb081e41a718d73183b0e1b76bfff66e92f7e1</id>
<content type='text'>
The Tegra194 BPMP only implements 5 channels (4 to BPMP, 1 to CCPLEX),
and they are not placed contiguously in memory. The current channel
management in the BPMP driver does not support this.

Simplify and refactor the channel management such that only one atomic
transmit channel and one receive channel are supported, and channels
are not required to be placed contiguously in memory. The same
configuration also works on T186 so we end up with less code.

Signed-off-by: Mikko Perttunen &lt;mperttunen@nvidia.com&gt;
Signed-off-by: Thierry Reding &lt;treding@nvidia.com&gt;
</content>
</entry>
<entry>
<title>Merge tag 'arc-4.15-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc</title>
<updated>2018-03-01T22:32:23Z</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2018-03-01T22:32:23Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=2120447b5dbda530a5c13cbc77cf20336465a5b4'/>
<id>urn:sha1:2120447b5dbda530a5c13cbc77cf20336465a5b4</id>
<content type='text'>
Pull ARC fixes from Vineet Gupta:

 - MCIP aka ARconnect fixes for SMP builds [Euginey]

 - preventive fix for SLC (L2 cache) flushing [Euginey]

 - Kconfig default fix [Ulf Magnusson]

 - trailing semicolon fixes [Luis de Bethencourt]

 - other assorted minor fixes

* tag 'arc-4.15-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc:
  ARC: setup cpu possible mask according to possible-cpus dts property
  ARC: mcip: update MCIP debug mask when the new cpu came online
  ARC: mcip: halt GFRC counter when ARC cores halt
  ARCv2: boot log: fix HS48 release number
  arc: dts: use 'atmel' as manufacturer for at24 in axs10x_mb
  ARC: Fix malformed ARC_EMUL_UNALIGNED default
  ARC: boot log: Fix trailing semicolon
  ARC: dw2 unwind: Fix trailing semicolon
  ARC: Enable fatal signals on boot for dev platforms
  ARCv2: Don't pretend we may set L-bit in STATUS32 with kflag instruction
  ARCv2: cache: fix slc_entire_op: flush only instead of flush-n-inv
</content>
</entry>
<entry>
<title>ARC: mcip: update MCIP debug mask when the new cpu came online</title>
<updated>2018-02-28T18:45:31Z</updated>
<author>
<name>Eugeniy Paltsev</name>
<email>Eugeniy.Paltsev@synopsys.com</email>
</author>
<published>2018-02-23T16:41:53Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=f3205de98db2fc8083796dd5ad81b191e436fab8'/>
<id>urn:sha1:f3205de98db2fc8083796dd5ad81b191e436fab8</id>
<content type='text'>
As of today we use hardcoded MCIP debug mask, so if we launch
kernel via debugger and kick fever cores than HW has all cpus
hang at the momemt of setup MCIP debug mask.

So update MCIP debug mask when the new cpu came online, instead of
use hardcoded MCIP debug mask.

Signed-off-by: Eugeniy Paltsev &lt;Eugeniy.Paltsev@synopsys.com&gt;
Signed-off-by: Vineet Gupta &lt;vgupta@synopsys.com&gt;
</content>
</entry>
<entry>
<title>ARC: mcip: halt GFRC counter when ARC cores halt</title>
<updated>2018-02-28T18:45:31Z</updated>
<author>
<name>Eugeniy Paltsev</name>
<email>Eugeniy.Paltsev@synopsys.com</email>
</author>
<published>2018-02-23T16:41:52Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=07423d00a2b2a71a97e4287d9262cb83c4c4c89f'/>
<id>urn:sha1:07423d00a2b2a71a97e4287d9262cb83c4c4c89f</id>
<content type='text'>
In SMP systems, GFRC is used for clocksource. However by default the
counter keeps running even when core is halted (say when debugging via a
JTAG debugger). This confuses Linux timekeeping and triggers flase RCU stall
splat such as below:

| [ARCLinux]# while true; do ./shm_open_23-1.run-test ; done
| Running with 1000 processes for 1000 objects
| hrtimer: interrupt took 485060 ns
|
| create_cnt: 1000
| Running with 1000 processes for 1000 objects
| [ARCLinux]# INFO: rcu_preempt self-detected stall on CPU
|       2-...: (1 GPs behind) idle=a01/1/0 softirq=135770/135773 fqs=0
| INFO: rcu_preempt detected stalls on CPUs/tasks:
| 	0-...: (1 GPs behind) idle=71e/0/0 softirq=135264/135264 fqs=0
|	2-...: (1 GPs behind) idle=a01/1/0 softirq=135770/135773 fqs=0
|	3-...: (1 GPs behind) idle=4e0/0/0 softirq=134304/134304 fqs=0
|	(detected by 1, t=13648 jiffies, g=31493, c=31492, q=1)

Starting from ARC HS v3.0 it's possible to tie GFRC to state of up-to 4
ARC cores with help of GFRC's CORE register where we set a mask for
cores which state we need to rely on.

We update cpu mask every time new cpu came online instead of using
hardcoded one or using mask generated from "possible_cpus" as we
want it set correctly even if we run kernel on HW which has fewer cores
than expected (or we launch kernel via debugger and kick fever cores
than HW has)

Note that GFRC halts when all cores have halted and thus relies on
programming of Inter-Core-dEbug register to halt all cores when one
halts.

Signed-off-by: Alexey Brodkin &lt;abrodkin@synopsys.com&gt;
Signed-off-by: Eugeniy Paltsev &lt;Eugeniy.Paltsev@synopsys.com&gt;
Signed-off-by: Vineet Gupta &lt;vgupta@synopsys.com&gt;
[vgupta: rewrote changelog]
</content>
</entry>
<entry>
<title>soc: bcm2835: sync firmware properties with downstream</title>
<updated>2018-02-22T12:46:35Z</updated>
<author>
<name>Baruch Siach</name>
<email>baruch@tkos.co.il</email>
</author>
<published>2018-02-20T12:19:31Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=08af112e79cab22f318ca0ad1a48187eee5ac2f0'/>
<id>urn:sha1:08af112e79cab22f318ca0ad1a48187eee5ac2f0</id>
<content type='text'>
Add latest firmware property tags from the latest Raspberry Pi downstream
kernel. This is needed for the GPIO tags, so we can control the GPIO
multiplexor lines.

Acked-by: Stefan Wahren &lt;stefan.wahren@i2se.com&gt;
Signed-off-by: Baruch Siach &lt;baruch@tkos.co.il&gt;
Signed-off-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
</content>
</entry>
</feed>
