* [GIT PULL 2/4] DaVinci SoC updates for v4.10 (part 3)
From: Sekhar Nori @ 2016-11-28 11:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161128114219.22325-1-nsekhar@ti.com>
The following changes since commit 7e431af8fa0b9ed9d74378c99514856211cb9db8:
ARM: davinci: PM: support da8xx DT platforms (2016-11-16 14:45:07 +0530)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v4.10/soc-3
for you to fetch changes up to b5e1438cf98a1c588726b0f861178f9aa5a96caf:
ARM: davinci: da830-evm: use gpio descriptor for mmc pins (2016-11-28 14:01:17 +0530)
----------------------------------------------------------------
mach-davinci SoC support updates to adjust
USB ohci device name to that used by drivers
and update of various board files to use gpio
descriptor API used by MMC subsystem for card
detect and write-protect detection.
----------------------------------------------------------------
Axel Haslam (4):
ARM: davinci: da8xx: Fix ohci device name
ARM: davinci: hawk: use gpio descriptor for mmc pins
ARM: davinci: da850-evm: use gpio descriptor for mmc pins
ARM: davinci: da830-evm: use gpio descriptor for mmc pins
arch/arm/mach-davinci/board-da830-evm.c | 41 ++++++++--------------------
arch/arm/mach-davinci/board-da850-evm.c | 35 +++++++-----------------
arch/arm/mach-davinci/board-omapl138-hawk.c | 42 ++++++++---------------------
arch/arm/mach-davinci/da830.c | 2 +-
arch/arm/mach-davinci/da850.c | 2 +-
arch/arm/mach-davinci/da8xx-dt.c | 2 +-
arch/arm/mach-davinci/usb-da8xx.c | 4 +--
7 files changed, 37 insertions(+), 91 deletions(-)
^ permalink raw reply
* [GIT PULL 1/4] DaVinci driver updates for v4.10 (part 2)
From: Sekhar Nori @ 2016-11-28 11:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161128114219.22325-1-nsekhar@ti.com>
The following changes since commit 8e7223fc8626db7c302136747bb68213100d290c:
bus: davinci: add support for da8xx bus master priority control (2016-11-14 17:20:29 +0530)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci.git tags/davinci-for-v4.10/drivers-2
for you to fetch changes up to d0c7546f6257b4680a760e3fd0dff8a7cc4600ff:
memory: da8xx-ddrctl: drop the call to of_flat_dt_get_machine_name() (2016-11-23 20:26:42 +0530)
----------------------------------------------------------------
Fixes for drivers already queued to prevent
section mismatch warnings introduced by them.
----------------------------------------------------------------
Bartosz Golaszewski (2):
bus: da8xx-mstpri: drop the call to of_flat_dt_get_machine_name()
memory: da8xx-ddrctl: drop the call to of_flat_dt_get_machine_name()
drivers/bus/da8xx-mstpri.c | 4 +---
drivers/memory/da8xx-ddrctl.c | 4 +---
2 files changed, 2 insertions(+), 6 deletions(-)
^ permalink raw reply
* [GIT PULL 0/4] DaVinci for v4.10 (set #4)
From: Sekhar Nori @ 2016-11-28 11:42 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This is the fourth set of DaVinci pull requests for v4.10.
The first two were picked up, the third one is pending:
https://www.spinics.net/lists/arm-kernel/msg543902.html
Please pull above before pulling this one.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 7/10] mmc: sdhci-xenon: Add support to PHYs of Marvell Xenon SDHC
From: Ziji Hu @ 2016-11-28 11:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAPDyKFo3ezYOywtSZ8GGQ1XK9KPsxCgQNbaiz45EVgbgtnUxjg@mail.gmail.com>
Hi Ulf,
On 2016/11/28 19:13, Ulf Hansson wrote:
>>
>> As you suggest, I replace mmc_wait_for_cmd() with mmc_send_tuning(), to
>> send commands for testing current sampling point set in our host PHY.
>>
>> According to my test result, it shows that mmc_send_tuning() can only support
>> tuning command (CMD21/CMD19).
>> As a result, we cannot use mmc_send_tuning() when card is in the speed modes
>> which doesn't support tuning, such as eMMC HS SDR, eMMC HS DRR and
>> SD SDR 12/SDR25/DDR50. Card will not response to tuning commands in those
>> speed modes.
>>
>> Could you please provide suggestions for the speed mode in which tuning is
>> not available?
>>
>
> Normally the mmc host driver shouldn't have to care about what the
> card supports, as that is the responsibility of the mmc core to
> manage.
>
> The host should only need to implement the ->execute_tuning() ops,
> which gets called when the card supports tuning (CMD19/21). Does it
> make sense?
>
I think it is irrelevant to tuning procedure.
Our host requires to adjust PHY setting after each time ios setting
(SDCLK/bus width/speed mode) is changed.
The simplified sequence is:
mmc change ios --> mmc_set_ios() --> ->set_ios() --> after sdhci_set_ios(),
adjust PHY setting.
During PHY setting adjustment, out host driver has to send commands to
test current sampling point. Tuning is another independent step.
Thus our host needs a valid command in PHY setting adjustment. Tuning command
can be borrowed to complete this task in SD SDR50. But for other speed mode,
we have to find out a valid command.
Any suggestion please?
Thank you.
Best regards,
Hu Ziji
> Kind regards
> Uffe
>
^ permalink raw reply
* [PATCH v2] drm: tilcdc: fix parsing of some DT properties
From: Bartosz Golaszewski @ 2016-11-28 11:37 UTC (permalink / raw)
To: linux-arm-kernel
The DT binding for tildc is not consistent with the driver code: there
are two options - 'max-width' and 'max-pixelclock' specified in the
documentation which are parsed as 'ti,max-width' and
'ti'max-pixelclock' respectively.
Make the driver code consistent with the binding.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
---
v1 -> v2:
- fix max-pixelclock too
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/tilcdc/tilcdc_drv.c b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
index 5efb369..bd0a3bd 100644
--- a/drivers/gpu/drm/tilcdc/tilcdc_drv.c
+++ b/drivers/gpu/drm/tilcdc/tilcdc_drv.c
@@ -296,12 +296,12 @@ static int tilcdc_init(struct drm_driver *ddrv, struct device *dev)
DBG("Maximum Bandwidth Value %d", priv->max_bandwidth);
- if (of_property_read_u32(node, "ti,max-width", &priv->max_width))
+ if (of_property_read_u32(node, "max-width", &priv->max_width))
priv->max_width = TILCDC_DEFAULT_MAX_WIDTH;
DBG("Maximum Horizontal Pixel Width Value %dpixels", priv->max_width);
- if (of_property_read_u32(node, "ti,max-pixelclock",
+ if (of_property_read_u32(node, "max-pixelclock",
&priv->max_pixelclock))
priv->max_pixelclock = TILCDC_DEFAULT_MAX_PIXELCLOCK;
--
2.9.3
^ permalink raw reply related
* [Qemu-devel] [kvm-unit-tests PATCH v7 03/11] run_tests: allow passing of options to QEMU
From: Alex Bennée @ 2016-11-28 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161128091051.zvtsvoow34b2nd5w@kamzik.brq.redhat.com>
Andrew Jones <drjones@redhat.com> writes:
> On Thu, Nov 24, 2016 at 04:10:25PM +0000, Alex Benn?e wrote:
>> This introduces a the option -o for passing of options directly to QEMU
>> which is useful. In my case I'm using it to toggle MTTCG on an off:
>>
>> ./run_tests.sh -t -o "-tcg mttcg=on"
>>
>> Signed-off-by: Alex Benn?e <alex.bennee@linaro.org>
>> ---
>> run_tests.sh | 10 +++++++---
>> scripts/functions.bash | 13 +++++++------
>> 2 files changed, 14 insertions(+), 9 deletions(-)
>>
>> diff --git a/run_tests.sh b/run_tests.sh
>> index 4f2e5cb..05cc7fb 100755
>> --- a/run_tests.sh
>> +++ b/run_tests.sh
>> @@ -13,10 +13,11 @@ function usage()
>> {
>> cat <<EOF
>>
>> -Usage: $0 [-g group] [-a accel] [-t] [-h] [-v]
>> +Usage: $0 [-g group] [-a accel] [-o qemu_opts] [-t] [-h] [-v]
>>
>> -g: Only execute tests in the given group
>> -a: Force acceleration mode (tcg/kvm)
>> + -o: additional options for QEMU command line
>> -t: disable timeouts
>> -h: Output this help text
>> -v: Enables verbose mode
>> @@ -30,7 +31,7 @@ EOF
>> RUNTIME_arch_run="./$TEST_DIR/run"
>> source scripts/runtime.bash
>>
>> -while getopts "g:a:thv" opt; do
>> +while getopts "g:a:o:thv" opt; do
>> case $opt in
>> g)
>> only_group=$OPTARG
>> @@ -38,6 +39,9 @@ while getopts "g:a:thv" opt; do
>> a)
>> force_accel=$OPTARG
>> ;;
>> + o)
>> + extra_opts=$OPTARG
>> + ;;
>> t)
>> no_timeout="yes"
>> ;;
>> @@ -67,4 +71,4 @@ RUNTIME_log_stdout () {
>> config=$TEST_DIR/unittests.cfg
>> rm -f test.log
>> printf "BUILD_HEAD=$(cat build-head)\n\n" > test.log
>> -for_each_unittest $config run
>> +for_each_unittest $config run "$extra_opts"
>> diff --git a/scripts/functions.bash b/scripts/functions.bash
>> index ee9143c..d38a69e 100644
>> --- a/scripts/functions.bash
>> +++ b/scripts/functions.bash
>> @@ -2,11 +2,12 @@
>> function for_each_unittest()
>> {
>> local unittests="$1"
>> - local cmd="$2"
>> - local testname
>> + local cmd="$2"
>> + local extra_opts=$3
>> + local testname
>
> We use tabs in this file. Not sure why cmd and testname got
> changed too...
>
>> local smp
>> local kernel
>> - local opts
>> + local opts=$extra_opts
>> local groups
>> local arch
>> local check
>> @@ -21,7 +22,7 @@ function for_each_unittest()
>> testname=${BASH_REMATCH[1]}
>> smp=1
>> kernel=""
>> - opts=""
>> + opts=$extra_opts
>> groups=""
>> arch=""
>> check=""
>> @@ -32,7 +33,7 @@ function for_each_unittest()
>> elif [[ $line =~ ^smp\ *=\ *(.*)$ ]]; then
>> smp=${BASH_REMATCH[1]}
>> elif [[ $line =~ ^extra_params\ *=\ *(.*)$ ]]; then
>> - opts=${BASH_REMATCH[1]}
>> + opts="$opts ${BASH_REMATCH[1]}"
>> elif [[ $line =~ ^groups\ *=\ *(.*)$ ]]; then
>> groups=${BASH_REMATCH[1]}
>> elif [[ $line =~ ^arch\ *=\ *(.*)$ ]]; then
>> @@ -45,6 +46,6 @@ function for_each_unittest()
>> timeout=${BASH_REMATCH[1]}
>> fi
>> done
>> - "$cmd" "$testname" "$groups" "$smp" "$kernel" "$opts" "$arch" "$check" "$accel" "$timeout"
>> + "$cmd" "$testname" "$groups" "$smp" "$kernel" "$opts" "$arch" "$check" "$accel" "$timeout"
>> exec {fd}<&-
>> }
>> --
>> 2.10.1
>>
>>
>
> This is a pretty good idea, but I think I might like the extra options
> to be given like this instead
>
> ./run_tests.sh [run_tests.sh options] -- [qemu options]
>
> Thanks,
> drew
That sounds like a better way, I'll fix that.
--
Alex Benn?e
^ permalink raw reply
* Adding a .platform_init callback to sdhci_arasan_ops
From: Sebastian Frias @ 2016-11-28 11:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2a949ade-edd7-4690-cd6a-434ae1e663dc@intel.com>
Hi Adrian,
On 28/11/16 11:30, Adrian Hunter wrote:
> On 28/11/16 09:32, Michal Simek wrote:
>> +Sai for Xilinx perspective.
>>
>> On 25.11.2016 16:24, Sebastian Frias wrote:
>>> Hi,
>>>
>>> When using the Arasan SDHCI HW IP, there is a set of parameters called
>>> "Hardware initialized registers"
>>>
>>> (Table 7, Section "Pin Signals", page 56 of Arasan "SD3.0/SDIO3.0/eMMC4.4
>>> AHB Host Controller", revision 6.0 document)
>>>
>>> In some platforms those signals are connected to registers that need to
>>> be programmed at some point for proper driver/HW initialisation.
>>>
>>> I found that the 'struct sdhci_ops' contains a '.platform_init' callback
>>> that is called from within 'sdhci_pltfm_init', and that seems a good
>>> candidate for a place to program those registers (*).
>>>
>>> Do you agree?
>
> We already killed .platform_init
I just saw that, yet it was the perfect place for the HW initialisation I'm
talking about.
Any way we can restore it?
>
> What is wrong with sdhci_arasan_probe()?
Well, in 4.7 sdhci_arasan_probe() did not call of_match_device(), so I had
put a call to it just before sdhci_pltfm_init(), something like:
+static const struct of_device_id sdhci_arasan_of_match[] = {
+ {
+ .compatible = "arasan,sdhci-8.9a",
+ .data = &sdhci_arasan_ops,
+ },
+ {
+ .compatible = "arasan,sdhci-5.1",
+ .data = &sdhci_arasan_ops,
+ },
+ {
+ .compatible = "arasan,sdhci-4.9a",
+ .data = &sdhci_arasan_ops,
+ },
+ {
+ .compatible = "sigma,smp8734-sdio",
+ .data = &sdhci_arasan_tango4_ops,
+ },
+ { }
+};
+MODULE_DEVICE_TABLE(of, sdhci_arasan_of_match);
...
+ const struct of_device_id *match;
+
+ match = of_match_device(sdhci_arasan_of_match, &pdev->dev);
+ if (match)
+ sdhci_arasan_pdata.ops = match->data;
where 'sdhci_arasan_tango4_ops' contained a pointer to a .platform_init
callback.
However, as I stated earlier, an upstream commit:
commit 3ea4666e8d429223fbb39c1dccee7599ef7657d5
Author: Douglas Anderson <dianders@chromium.org>
Date: Mon Jun 20 10:56:47 2016 -0700
mmc: sdhci-of-arasan: Properly set corecfg_baseclkfreq on rk3399
changed struct 'sdhci_arasan_of_match' to convey different data, which
means that instead of having a generic way of accessing such data (such
as 'of_match_device()' and ".data" field), one must also check for
specific "compatible" strings to make sense of the ".data" field, such as
"rockchip,rk3399-sdhci-5.1"
With the current code:
- there's no 'of_match_device()' before 'sdhci_pltfm_init()'
- the sdhci_pltfm_init() call is made with a static 'sdhci_arasan_pdata'
struct (so it cannot be made dependent on the "compatible" string).
- since 'sdhci_arasan_pdata' is the same for all compatible devices, even
for those that require special handling, more "compatible" matching code is
required
- leading to spread "compatible" matching code; IMHO it would be cleaner if
the 'sdhci_arasan_probe()' code was generic, with just a generic "compatible"
matching, which then proceeded with specific initialisation and generic
initialisation.
In a nutshell, IMHO it would be better if adding support for more SoCs only
involved changing just 'sdhci_arasan_of_match' without the need to change
'sdhci_arasan_probe()'.
That would clearly separate the generic and "SoC"-specific code, thus allowing
better maintenance.
Does that makes sense to you guys?
Best regards,
Sebastian
>
>>>
>>> Best regards,
>>>
>>> Sebastian
>>>
>>>
>>> (*): This has been prototyped on 4.7 as working properly.
>>> However, upstream commit:
>>>
>>> commit 3ea4666e8d429223fbb39c1dccee7599ef7657d5
>>> Author: Douglas Anderson <dianders@chromium.org>
>>> Date: Mon Jun 20 10:56:47 2016 -0700
>>>
>>> mmc: sdhci-of-arasan: Properly set corecfg_baseclkfreq on rk3399
>>> ...
>>>
>>> could affect this solution because of the way the 'sdhci_arasan_of_match'
>>> struct is used after that commit.
>>>
>>
>>
>
^ permalink raw reply
* [PATCH] ARM: dts: sunxi: Enable UEXT related nodes for Olimex A20 SOM EVB
From: Maxime Ripard @ 2016-11-28 11:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124210834.a7da24a53b09364e8ab391d6@bidouilliste.com>
On Thu, Nov 24, 2016 at 09:08:34PM +0100, Emmanuel Vadot wrote:
> On Wed, 23 Nov 2016 18:16:10 +0100
> Emmanuel Vadot <manu@bidouilliste.com> wrote:
>
> > On Wed, 23 Nov 2016 09:03:50 +0100
> > Maxime Ripard <maxime.ripard@free-electrons.com> wrote:
> >
> > > On Mon, Nov 21, 2016 at 05:49:11PM +0100, Emmanuel Vadot wrote:
> > > > UEXT are Universal EXTension connector from Olimex. They embed i2c, spi
> > > > and uart pins along power in one connector and are found on most,
> > > > if not all, Olimex boards.
> > > > The Olimex A20 SOM EVB have two UEXT connector so enable the nodes found on
> > > > those two connectors.
> > > >
> > > > Signed-off-by: Emmanuel Vadot <manu@bidouilliste.com>
> > >
> > > Fixed the indentation of the spi pinctrl cells, and applied.
> > >
> > > Please note that I'm note planning to send any new pull request, so
> > > this will likely end up in 4.11.
> > >
> > > Thanks!
> > > Maxime
> > >
> > > --
> > > Maxime Ripard, Free Electrons
> > > Embedded Linux and Kernel engineering
> > > http://free-electrons.com
> >
> > Sorry about the indentation, I'll be more carefull next time.
> >
> > Thank you.
> >
> > --
> > Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
> >
>
> Hi Maxime,
>
> Re-reading the patch I've seen that I've not enabled the SPI nodes, I
> guess it's easier if you revert my patch and that I send a new one ?
Just send the missing nodes, I'll squash the two commits.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161128/9bf0ed1f/attachment-0001.sig>
^ permalink raw reply
* [Qemu-devel] [kvm-unit-tests PATCH v7 00/11] QEMU MTTCG Test cases
From: Peter Maydell @ 2016-11-28 11:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <878ts3uac6.fsf@linaro.org>
On 28 November 2016 at 11:12, Alex Benn?e <alex.bennee@linaro.org> wrote:
>
> Andrew Jones <drjones@redhat.com> writes:
>> I've skimmed over everything looking at it from a framwork/sytle
>> perspective. I didn't dig in trying to understand the tests though.
>> One general comment, I see many tests introduce MAX_CPUS 8. Why do
>> that? Why not allow all cpus by using NR_CPUS for the array sizes?
>
> Yeah - I can fix those. I wonder what the maximum is with GIC V3?
So large that you don't want to hardcode it as an array size...
thanks
-- PMM
^ permalink raw reply
* [PATCH 7/10] mmc: sdhci-xenon: Add support to PHYs of Marvell Xenon SDHC
From: Ulf Hansson @ 2016-11-28 11:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8359307d-5f44-3db9-aae1-eb1fe8e1141d@marvell.com>
>
> As you suggest, I replace mmc_wait_for_cmd() with mmc_send_tuning(), to
> send commands for testing current sampling point set in our host PHY.
>
> According to my test result, it shows that mmc_send_tuning() can only support
> tuning command (CMD21/CMD19).
> As a result, we cannot use mmc_send_tuning() when card is in the speed modes
> which doesn't support tuning, such as eMMC HS SDR, eMMC HS DRR and
> SD SDR 12/SDR25/DDR50. Card will not response to tuning commands in those
> speed modes.
>
> Could you please provide suggestions for the speed mode in which tuning is
> not available?
>
Normally the mmc host driver shouldn't have to care about what the
card supports, as that is the responsibility of the mmc core to
manage.
The host should only need to implement the ->execute_tuning() ops,
which gets called when the card supports tuning (CMD19/21). Does it
make sense?
Kind regards
Uffe
^ permalink raw reply
* [Qemu-devel] [kvm-unit-tests PATCH v7 00/11] QEMU MTTCG Test cases
From: Alex Bennée @ 2016-11-28 11:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161128103744.s3wq53xzsxvu5uus@kamzik.brq.redhat.com>
Andrew Jones <drjones@redhat.com> writes:
> On Thu, Nov 24, 2016 at 04:10:22PM +0000, Alex Benn?e wrote:
>> Hi,
>>
>> Looking at my records it seems as though it has been a while since I
>> last posted these tests. As I'm hoping to get the final bits of MTTCG
>> merged upstream on the next QEMU development cycle I've been re-basing
>> these and getting them cleaned up for merging.
>>
>> Some of the patches might be worth taking now if the maintainers are
>> happy to do so (run_test tweaks, libcflat updates?). The others could
>> do with more serious review. I've CC'd some of the ARM guys to look
>> over the tlbflush/barrier tests so they can cast their expert eyes
>> over them ;-)
>>
>> There are two additions to the series.
>>
>> The tcg-test is a general torture test aimed at QEMU's TCG execution
>> model. It stresses the cpu execution loop through the use of
>> cross-page and computed jumps. It can also add IRQ's and self-modifying
>> code to the mix.
>>
>> The tlbflush-data test is a new one, the old tlbflush test is renamed
>> tlbflush-code to better indicate the code path it exercise. The the
>> code test tests the translation invalidation pathways in QEMU the data
>> test exercises the SoftMMU's TLBs and explicitly that tlbflush
>> completion semantics are correct.
>>
>> The tlbflush-data passes most of the times on real hardware but
>> definitely showed the problem with deferred TLB flushes running under
>> MTTCG QEMU. I've looked at some of the failure cases on real hardware
>> and it did look like a timestamp appeared on a page that shouldn't
>> have been accessible at the time - I don't know if this is a real
>> silicon bug or my misreading of the semantics so I'd appreciate
>> a comment from the experts.
>>
>> The code needs to be applied on top of Drew's latest ARM GIC patches
>> or you can grab my tree from:
>>
>> https://github.com/stsquad/kvm-unit-tests/tree/mttcg/current-tests-v7
>
> Thanks Alex,
>
> I've skimmed over everything looking at it from a framwork/sytle
> perspective. I didn't dig in trying to understand the tests though.
> One general comment, I see many tests introduce MAX_CPUS 8. Why do
> that? Why not allow all cpus by using NR_CPUS for the array sizes?
Yeah - I can fix those. I wonder what the maximum is with GIC V3?
>
> Thanks,
> drew
>
>>
>> Cheers,
>>
>> Alex.
>>
>> Alex Benn?e (11):
>> run_tests: allow forcing of acceleration mode
>> run_tests: allow disabling of timeouts
>> run_tests: allow passing of options to QEMU
>> libcflat: add PRI(dux)32 format types
>> lib: add isaac prng library from CCAN
>> arm/Makefile.common: force -fno-pic
>> arm/tlbflush-code: Add TLB flush during code execution test
>> arm/tlbflush-data: Add TLB flush during data writes test
>> arm/locking-tests: add comprehensive locking test
>> arm/barrier-litmus-tests: add simple mp and sal litmus tests
>> arm/tcg-test: some basic TCG exercising tests
>>
>> Makefile | 2 +
>> arm/Makefile.arm | 2 +
>> arm/Makefile.arm64 | 2 +
>> arm/Makefile.common | 11 ++
>> arm/barrier-litmus-test.c | 437 ++++++++++++++++++++++++++++++++++++++++++++++
>> arm/locking-test.c | 302 ++++++++++++++++++++++++++++++++
>> arm/tcg-test-asm.S | 170 ++++++++++++++++++
>> arm/tcg-test-asm64.S | 169 ++++++++++++++++++
>> arm/tcg-test.c | 337 +++++++++++++++++++++++++++++++++++
>> arm/tlbflush-code.c | 212 ++++++++++++++++++++++
>> arm/tlbflush-data.c | 401 ++++++++++++++++++++++++++++++++++++++++++
>> arm/unittests.cfg | 190 ++++++++++++++++++++
>> lib/arm/asm/barrier.h | 63 ++++++-
>> lib/arm64/asm/barrier.h | 50 ++++++
>> lib/libcflat.h | 5 +
>> lib/prng.c | 162 +++++++++++++++++
>> lib/prng.h | 82 +++++++++
>> run_tests.sh | 18 +-
>> scripts/functions.bash | 13 +-
>> scripts/runtime.bash | 8 +
>> 20 files changed, 2626 insertions(+), 10 deletions(-)
>> create mode 100644 arm/barrier-litmus-test.c
>> create mode 100644 arm/locking-test.c
>> create mode 100644 arm/tcg-test-asm.S
>> create mode 100644 arm/tcg-test-asm64.S
>> create mode 100644 arm/tcg-test.c
>> create mode 100644 arm/tlbflush-code.c
>> create mode 100644 arm/tlbflush-data.c
>> create mode 100644 lib/prng.c
>> create mode 100644 lib/prng.h
>>
>> --
>> 2.10.1
>>
>>
--
Alex Benn?e
^ permalink raw reply
* [PATCH 7/10] mmc: sdhci-xenon: Add support to PHYs of Marvell Xenon SDHC
From: Ulf Hansson @ 2016-11-28 11:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <436c6925-cb0d-afe7-e3a2-384eca15ff42@marvell.com>
[...]
>
> Could you please tell me the requirement of "op_code" parameter in
> mmc_send_tuning()?
> According to mmc_send_tuning(),it seems that tuning command(CMD19/CMD21)
> is required. Thus device will not response mmc_send_tuning() if current
> speed mode doesn't support tuning command.
> Please correct me if I am wrong.
>
When the mmc core decides it's time to execute tuning, it invokes the
->execute_tuning() host ops, which has the "opcode" as a parameter.
You should be able to use it when calling mmc_send_tuning().
[...]
Kind regards
Uffe
^ permalink raw reply
* [PATCH] ARM: dts: mvebu: Add Armada 38x labels and clean up Turris Omnia
From: Russell King - ARM Linux @ 2016-11-28 10:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4ad1108a-43c4-46f8-4683-1c4b89996036@suse.de>
On Mon, Nov 28, 2016 at 11:52:26AM +0100, Andreas F?rber wrote:
> Hi Russell,
>
> Am 28.11.2016 um 11:37 schrieb Russell King - ARM Linux:
> > On Sun, Nov 27, 2016 at 07:51:39PM +0100, Andreas F?rber wrote:
> >> To more consistently reference nodes by label, add labels for sata,
> >> usb2, sdhci and usb3 nodes.
> >>
> >> Convert all other 38x boards for consistency. Add labels for nfc and rtc.
> >
> > Please don't do this for clearfog - there's changes in the pipeline which
> > completely replace armada-388-clearfog.dts because there's a "base" and
> > "pro" versions of this hardware now, and making such a huge change will
> > effectively mean we have to start over with the DT files.
>
> Would it help to split it back up into a series of add-labels,
> use-labels like I had originally? Then you could start using them in
> your refactoring as soon as the add-labels patch gets applied. Or are
> you completely against this style?
What I mentioned is not a case of a work in progress, it's already out
in the wild, and completely changing the clearfog dts file by changing
the style of DT references will make applying the changes _much_ more
difficult - not only obviously impossible to apply the original patch,
but also quite impossible to identify the changes made downstream.
So, I'd rather armada-388-clearfog.dts is not touched at all as it _will_
cause conflicts, but I have nothing against the new style (and I actually
prefer it.)
What I'm asking is that you don't make other people's lives harder than
they need to be.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] ARM: dts: mvebu: Add Armada 38x labels and clean up Turris Omnia
From: Andreas Färber @ 2016-11-28 10:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e29e1a96-c9d5-d9b1-a42d-8afddc2714a7@kleine-koenig.org>
Hi,
Am 28.11.2016 um 11:54 schrieb Uwe Kleine-K?nig:
> On 11/28/2016 11:52 AM, Andreas F?rber wrote:
>> Would it help to split it back up into a series of add-labels,
>> use-labels like I had originally? Then you could start using them in
>> your refactoring as soon as the add-labels patch gets applied. Or are
>> you completely against this style?
>
> I'd even go as far as:
>
> 1: add labels to .dtsi
> 2: use labels on .dts#1
> 3: use labels on .dts#2
> ...
That was what I had in mind. :) I even considered reusing the existing
labels first, then adding more and converting more nodes.
Making the patches smaller will hopefully make them more easily
reviewable at the same time.
Cheers,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)
^ permalink raw reply
* [PATCH] ARM: dts: mvebu: Add Armada 38x labels and clean up Turris Omnia
From: Uwe Kleine-König @ 2016-11-28 10:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4ad1108a-43c4-46f8-4683-1c4b89996036@suse.de>
Hello,
On 11/28/2016 11:52 AM, Andreas F?rber wrote:
>> Please don't do this for clearfog - there's changes in the pipeline which
>> completely replace armada-388-clearfog.dts because there's a "base" and
>> "pro" versions of this hardware now, and making such a huge change will
>> effectively mean we have to start over with the DT files.
>
> Would it help to split it back up into a series of add-labels,
> use-labels like I had originally? Then you could start using them in
> your refactoring as soon as the add-labels patch gets applied. Or are
> you completely against this style?
I'd even go as far as:
1: add labels to .dtsi
2: use labels on .dts#1
3: use labels on .dts#2
...
Best regards
Uwe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161128/10666366/attachment.sig>
^ permalink raw reply
* [bug report v4.8] fs/locks.c: kernel oops during posix lock stress test
From: Will Deacon @ 2016-11-28 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACVXFVPsHjh3CWjdUrKB_r6=hkXK=qS3wpykbacdKe1rzz1H8Q@mail.gmail.com>
Hi Ming,
On Mon, Nov 28, 2016 at 11:10:14AM +0800, Ming Lei wrote:
> When I run stress-ng via the following steps on one ARM64 dual
> socket system(Cavium Thunder), the kernel oops[1] can often be
> triggered after running the stress test for several hours(sometimes
> it may take longer):
>
> - git clone git://kernel.ubuntu.com/cking/stress-ng.git
> - apply the attachment patch which just makes the posix file
> lock stress test more aggressive
> - run the test via '~/git/stress-ng$./stress-ng --lockf 128 --aggressive'
>
>
> From the oops log, looks one garbage file_lock node is got
> from the linked list of 'ctx->flc_posix' when the issue happens.
>
> BTW, the issue isn't observed on single socket Cavium Thunder yet,
> and the same issue can be seen on Ubuntu Xenial(v4.4 based kernel)
> too.
I've seen issues with the LSE atomics on the Thunder platform -- can you
try disabling those (CONFIG_ARM64_LSE_ATOMICS) and see if the problem
persists, please?
Will
^ permalink raw reply
* [PATCH V7 1/3] ACPI: Retry IRQ conversion if it failed previously
From: majun (Euler7) @ 2016-11-28 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479074375-2629-2-git-send-email-agustinv@codeaurora.org>
This patch works fine on my D05 board.
Tested-by: Majun <majun258@huawei.com>
? 2016/11/14 5:59, Agustin Vega-Frias ??:
> This allows probe deferral to work properly when a dependent device
> fails to get a valid IRQ because the IRQ domain was not registered
> at the time the resources were added to the platform_device.
>
> Signed-off-by: Agustin Vega-Frias <agustinv@codeaurora.org>
> ---
> drivers/acpi/resource.c | 59 +++++++++++++++++++++++++++++++++++++++++++++++++
> drivers/base/platform.c | 9 +++++++-
> include/linux/acpi.h | 7 ++++++
> 3 files changed, 74 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> index 56241eb..4beda15 100644
> --- a/drivers/acpi/resource.c
> +++ b/drivers/acpi/resource.c
> @@ -664,3 +664,62 @@ int acpi_dev_filter_resource_type(struct acpi_resource *ares,
> return (type & types) ? 0 : 1;
> }
> EXPORT_SYMBOL_GPL(acpi_dev_filter_resource_type);
> +
> +struct acpi_irq_get_ctx {
> + unsigned int index;
> + struct resource *res;
> +};
> +
> +static acpi_status acpi_irq_get_cb(struct acpi_resource *ares, void *context)
> +{
> + struct acpi_irq_get_ctx *ctx = context;
> + struct acpi_resource_irq *irq;
> + struct acpi_resource_extended_irq *ext_irq;
> +
> + switch (ares->type) {
> + case ACPI_RESOURCE_TYPE_IRQ:
> + irq = &ares->data.irq;
> + if (ctx->index < irq->interrupt_count) {
> + acpi_dev_resource_interrupt(ares, ctx->index, ctx->res);
> + return AE_CTRL_TERMINATE;
> + }
> + ctx->index -= irq->interrupt_count;
> + break;
> + case ACPI_RESOURCE_TYPE_EXTENDED_IRQ:
> + ext_irq = &ares->data.extended_irq;
> + if (ctx->index < ext_irq->interrupt_count) {
> + acpi_dev_resource_interrupt(ares, ctx->index, ctx->res);
> + return AE_CTRL_TERMINATE;
> + }
> + ctx->index -= ext_irq->interrupt_count;
> + break;
> + }
> +
> + return AE_OK;
> +}
> +
> +/**
> + * acpi_irq_get - Look for the ACPI IRQ resource with the given index and
> + * use it to initialize the given Linux IRQ resource.
> + * @handle ACPI device handle
> + * @index ACPI IRQ resource index to lookup
> + * @res Linux IRQ resource to initialize
> + *
> + * Return: 0 on success
> + * -EINVAL if an error occurs
> + * -EPROBE_DEFER if the IRQ lookup/conversion failed
> + */
> +int acpi_irq_get(acpi_handle handle, unsigned int index, struct resource *res)
> +{
> + struct acpi_irq_get_ctx ctx = { index, res };
> + acpi_status status;
> +
> + status = acpi_walk_resources(handle, METHOD_NAME__CRS,
> + acpi_irq_get_cb, &ctx);
> + if (ACPI_FAILURE(status))
> + return -EINVAL;
> + if (res->flags & IORESOURCE_DISABLED)
> + return -EPROBE_DEFER;
> + return 0;
> +}
> +EXPORT_SYMBOL_GPL(acpi_irq_get);
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index c4af003..61423d2 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -102,6 +102,14 @@ int platform_get_irq(struct platform_device *dev, unsigned int num)
> }
>
> r = platform_get_resource(dev, IORESOURCE_IRQ, num);
> + if (r && r->flags & IORESOURCE_DISABLED && ACPI_COMPANION(&dev->dev)) {
> + int ret;
> +
> + ret = acpi_irq_get(ACPI_HANDLE(&dev->dev), num, r);
> + if (ret)
> + return ret;
> + }
> +
> /*
> * The resources may pass trigger flags to the irqs that need
> * to be set up. It so happens that the trigger flags for
> @@ -1450,4 +1458,3 @@ void __init early_platform_cleanup(void)
> memset(&pd->dev.devres_head, 0, sizeof(pd->dev.devres_head));
> }
> }
> -
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index 689a8b9..325bdb9 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -406,6 +406,7 @@ bool acpi_dev_resource_ext_address_space(struct acpi_resource *ares,
> unsigned int acpi_dev_get_irq_type(int triggering, int polarity);
> bool acpi_dev_resource_interrupt(struct acpi_resource *ares, int index,
> struct resource *res);
> +int acpi_irq_get(acpi_handle handle, unsigned int index, struct resource *res);
>
> void acpi_dev_free_resource_list(struct list_head *list);
> int acpi_dev_get_resources(struct acpi_device *adev, struct list_head *list,
> @@ -763,6 +764,12 @@ static inline int acpi_reconfig_notifier_unregister(struct notifier_block *nb)
> return -EINVAL;
> }
>
> +static inline int acpi_irq_get(acpi_handle handle, unsigned int index,
> + struct resource *res)
> +{
> + return -EINVAL;
> +}
> +
> #endif /* !CONFIG_ACPI */
>
> #ifdef CONFIG_ACPI_HOTPLUG_IOAPIC
>
^ permalink raw reply
* [PATCH] ARM: dts: mvebu: Add Armada 38x labels and clean up Turris Omnia
From: Andreas Färber @ 2016-11-28 10:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161128103738.GT14217@n2100.armlinux.org.uk>
Hi Russell,
Am 28.11.2016 um 11:37 schrieb Russell King - ARM Linux:
> On Sun, Nov 27, 2016 at 07:51:39PM +0100, Andreas F?rber wrote:
>> To more consistently reference nodes by label, add labels for sata,
>> usb2, sdhci and usb3 nodes.
>>
>> Convert all other 38x boards for consistency. Add labels for nfc and rtc.
>
> Please don't do this for clearfog - there's changes in the pipeline which
> completely replace armada-388-clearfog.dts because there's a "base" and
> "pro" versions of this hardware now, and making such a huge change will
> effectively mean we have to start over with the DT files.
Would it help to split it back up into a series of add-labels,
use-labels like I had originally? Then you could start using them in
your refactoring as soon as the add-labels patch gets applied. Or are
you completely against this style?
Thanks for pointing this out,
Andreas
--
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Graham Norton
HRB 21284 (AG N?rnberg)
^ permalink raw reply
* [Qemu-devel] [kvm-unit-tests PATCH v7 00/11] QEMU MTTCG Test cases
From: Andrew Jones @ 2016-11-28 10:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124161033.11456-1-alex.bennee@linaro.org>
On Thu, Nov 24, 2016 at 04:10:22PM +0000, Alex Benn?e wrote:
> Hi,
>
> Looking at my records it seems as though it has been a while since I
> last posted these tests. As I'm hoping to get the final bits of MTTCG
> merged upstream on the next QEMU development cycle I've been re-basing
> these and getting them cleaned up for merging.
>
> Some of the patches might be worth taking now if the maintainers are
> happy to do so (run_test tweaks, libcflat updates?). The others could
> do with more serious review. I've CC'd some of the ARM guys to look
> over the tlbflush/barrier tests so they can cast their expert eyes
> over them ;-)
>
> There are two additions to the series.
>
> The tcg-test is a general torture test aimed at QEMU's TCG execution
> model. It stresses the cpu execution loop through the use of
> cross-page and computed jumps. It can also add IRQ's and self-modifying
> code to the mix.
>
> The tlbflush-data test is a new one, the old tlbflush test is renamed
> tlbflush-code to better indicate the code path it exercise. The the
> code test tests the translation invalidation pathways in QEMU the data
> test exercises the SoftMMU's TLBs and explicitly that tlbflush
> completion semantics are correct.
>
> The tlbflush-data passes most of the times on real hardware but
> definitely showed the problem with deferred TLB flushes running under
> MTTCG QEMU. I've looked at some of the failure cases on real hardware
> and it did look like a timestamp appeared on a page that shouldn't
> have been accessible at the time - I don't know if this is a real
> silicon bug or my misreading of the semantics so I'd appreciate
> a comment from the experts.
One other thought. I'm not sure how best to approach a bunch of TCG-only
tests getting integrated. I'm thinking it might be nice to give them
their own subdir under the arch dir, e.g. arm/tcg. That subdir would
have its own unittests.cfg file too. Otherwise when we run on KVM we'll
have a load of "SKIP: requires TCG" type messages...
We'll want to add a run_tests.sh option to pass the name of the subdir,
'-d tcg'. When the subdir name is 'tcg' ACCEL could automatically be
switched to 'tcg' as well.
Thanks,
drew
^ permalink raw reply
* [PATCH] ARM: dts: da850: specify the maximum bandwidth for tilcdc
From: Bartosz Golaszewski @ 2016-11-28 10:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <86f2b643-c270-1483-4f35-5bdf399a5919@ti.com>
2016-11-28 8:58 GMT+01:00 Sekhar Nori <nsekhar@ti.com>:
> On Monday 28 November 2016 01:12 PM, Tomi Valkeinen wrote:
>> On 28/11/16 07:24, Sekhar Nori wrote:
>>> On Friday 25 November 2016 09:07 PM, Bartosz Golaszewski wrote:
>>>> It has been determined that the maximum resolution supported correctly
>>>> by tilcdc rev1 on da850 SoCs is 800x600 at 60. Due to memory throughput
>>>> constraints we must filter out higher modes.
>>>>
>>>> Specify the max-bandwidth property for the display node for
>>>> da850-based boards.
>>>>
>>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>>> ---
>>>> arch/arm/boot/dts/da850.dtsi | 1 +
>>>> 1 file changed, 1 insertion(+)
>>>>
>>>> diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
>>>> index 8e30d9b..9b7c444 100644
>>>> --- a/arch/arm/boot/dts/da850.dtsi
>>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>>> @@ -452,6 +452,7 @@
>>>> compatible = "ti,da850-tilcdc";
>>>> reg = <0x213000 0x1000>;
>>>> interrupts = <52>;
>>>> + max-bandwidth = <28800000>;
>>>
>>> If this is effectively the max pixel clock that the device supports,
>>> then why not use the datasheet specified value of 37.5 MHz (Tc = 26.66 ns).
>>
>> There's a separate property for max-pixelclock. This one is maximum
>> pixels per second (which does sound almost the same), but the doc says
>> it's about the particular memory interface + LCDC combination.
>
> DA850 supports both mDDR and DDR2, at slightly different speeds. So
> memory bandwidth limitation is also board specific. This should probably
> move to board file.
>
> But I would like to know why using max-pixelclock is not good enough.
> Have experiments shown that LCDC on DA850 LCDK underflows even if pixel
> clock is below the datasheet recommendation?
>
Hi Sekhar,
I've just tested 1024x768 at 37000 KHz - indeed seems like the
underflows are gone as soon as we go below 37500 KHz. I'll submit a
new patch using the max-pixelclock property.
Thanks,
Bartosz Golaszewski
^ permalink raw reply
* [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3
From: Jean-Francois Moine @ 2016-11-28 10:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161128095900.27615-1-icenowy@aosc.xyz>
On Mon, 28 Nov 2016 17:59:00 +0800
Icenowy Zheng <icenowy@aosc.xyz> wrote:
> As there's currently a fork of U-Boot which provides simplefb support
> for H3, a simplefb node can be added to the device tree.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> ---
>
> I'm still not sure which pipeline should I use.
>
> And, it seems that HDMI Slow Clock is not needed?
>
> (seems that it's only for EDID, but simplefb won't use EDID)
So, I don't see how this may work.
How can the u-boot know the resolutions of the HDMI display device?
In other words: I have a new H3 board with the last u-boot and kernel.
I plug my (rather old or brand new) HDMI display device.
After powering on the system, I hope to get something on the screen.
How?
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [Qemu-devel] [kvm-unit-tests PATCH v7 00/11] QEMU MTTCG Test cases
From: Andrew Jones @ 2016-11-28 10:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124161033.11456-1-alex.bennee@linaro.org>
On Thu, Nov 24, 2016 at 04:10:22PM +0000, Alex Benn?e wrote:
> Hi,
>
> Looking at my records it seems as though it has been a while since I
> last posted these tests. As I'm hoping to get the final bits of MTTCG
> merged upstream on the next QEMU development cycle I've been re-basing
> these and getting them cleaned up for merging.
>
> Some of the patches might be worth taking now if the maintainers are
> happy to do so (run_test tweaks, libcflat updates?). The others could
> do with more serious review. I've CC'd some of the ARM guys to look
> over the tlbflush/barrier tests so they can cast their expert eyes
> over them ;-)
>
> There are two additions to the series.
>
> The tcg-test is a general torture test aimed at QEMU's TCG execution
> model. It stresses the cpu execution loop through the use of
> cross-page and computed jumps. It can also add IRQ's and self-modifying
> code to the mix.
>
> The tlbflush-data test is a new one, the old tlbflush test is renamed
> tlbflush-code to better indicate the code path it exercise. The the
> code test tests the translation invalidation pathways in QEMU the data
> test exercises the SoftMMU's TLBs and explicitly that tlbflush
> completion semantics are correct.
>
> The tlbflush-data passes most of the times on real hardware but
> definitely showed the problem with deferred TLB flushes running under
> MTTCG QEMU. I've looked at some of the failure cases on real hardware
> and it did look like a timestamp appeared on a page that shouldn't
> have been accessible at the time - I don't know if this is a real
> silicon bug or my misreading of the semantics so I'd appreciate
> a comment from the experts.
>
> The code needs to be applied on top of Drew's latest ARM GIC patches
> or you can grab my tree from:
>
> https://github.com/stsquad/kvm-unit-tests/tree/mttcg/current-tests-v7
Thanks Alex,
I've skimmed over everything looking at it from a framwork/sytle
perspective. I didn't dig in trying to understand the tests though.
One general comment, I see many tests introduce MAX_CPUS 8. Why do
that? Why not allow all cpus by using NR_CPUS for the array sizes?
Thanks,
drew
>
> Cheers,
>
> Alex.
>
> Alex Benn?e (11):
> run_tests: allow forcing of acceleration mode
> run_tests: allow disabling of timeouts
> run_tests: allow passing of options to QEMU
> libcflat: add PRI(dux)32 format types
> lib: add isaac prng library from CCAN
> arm/Makefile.common: force -fno-pic
> arm/tlbflush-code: Add TLB flush during code execution test
> arm/tlbflush-data: Add TLB flush during data writes test
> arm/locking-tests: add comprehensive locking test
> arm/barrier-litmus-tests: add simple mp and sal litmus tests
> arm/tcg-test: some basic TCG exercising tests
>
> Makefile | 2 +
> arm/Makefile.arm | 2 +
> arm/Makefile.arm64 | 2 +
> arm/Makefile.common | 11 ++
> arm/barrier-litmus-test.c | 437 ++++++++++++++++++++++++++++++++++++++++++++++
> arm/locking-test.c | 302 ++++++++++++++++++++++++++++++++
> arm/tcg-test-asm.S | 170 ++++++++++++++++++
> arm/tcg-test-asm64.S | 169 ++++++++++++++++++
> arm/tcg-test.c | 337 +++++++++++++++++++++++++++++++++++
> arm/tlbflush-code.c | 212 ++++++++++++++++++++++
> arm/tlbflush-data.c | 401 ++++++++++++++++++++++++++++++++++++++++++
> arm/unittests.cfg | 190 ++++++++++++++++++++
> lib/arm/asm/barrier.h | 63 ++++++-
> lib/arm64/asm/barrier.h | 50 ++++++
> lib/libcflat.h | 5 +
> lib/prng.c | 162 +++++++++++++++++
> lib/prng.h | 82 +++++++++
> run_tests.sh | 18 +-
> scripts/functions.bash | 13 +-
> scripts/runtime.bash | 8 +
> 20 files changed, 2626 insertions(+), 10 deletions(-)
> create mode 100644 arm/barrier-litmus-test.c
> create mode 100644 arm/locking-test.c
> create mode 100644 arm/tcg-test-asm.S
> create mode 100644 arm/tcg-test-asm64.S
> create mode 100644 arm/tcg-test.c
> create mode 100644 arm/tlbflush-code.c
> create mode 100644 arm/tlbflush-data.c
> create mode 100644 lib/prng.c
> create mode 100644 lib/prng.h
>
> --
> 2.10.1
>
>
^ permalink raw reply
* [PATCH] ARM: dts: mvebu: Add Armada 38x labels and clean up Turris Omnia
From: Russell King - ARM Linux @ 2016-11-28 10:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480272700-28888-1-git-send-email-afaerber@suse.de>
On Sun, Nov 27, 2016 at 07:51:39PM +0100, Andreas F?rber wrote:
> To more consistently reference nodes by label, add labels for sata,
> usb2, sdhci and usb3 nodes.
>
> Convert all other 38x boards for consistency. Add labels for nfc and rtc.
Please don't do this for clearfog - there's changes in the pipeline which
completely replace armada-388-clearfog.dts because there's a "base" and
"pro" versions of this hardware now, and making such a huge change will
effectively mean we have to start over with the DT files.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [net-next PATCH v1 0/2] stmmac: dwmac-meson8b: configurable RGMII TX delay
From: Sebastian Frias @ 2016-11-28 10:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1b7f113e-34f9-69f4-a45f-9fd687d87990@gmail.com>
On 25/11/16 18:44, Florian Fainelli wrote:
> On 11/25/2016 03:13 AM, Sebastian Frias wrote:
>> On 24/11/16 19:55, Florian Fainelli wrote:
<snip>
>>> Correct, the meaning of PHY_INTERFACE_MODE should be from the
>>> perspective of the PHY device:
>>>
>>> - PHY_INTERFACE_MODE_RGMII_TXID means that the PHY is responsible for
>>> adding a delay when the MAC transmits (TX MAC -> PHY (delay) -> wire)
>>> - PHY_INTERFACE_MODE_RGMII_RXID means that the PHY is responsible for
>>> adding a delay when the MAC receives (RX MAC <- (delay) PHY) <- wire)
>>>
>>
>> Thanks for the explanation.
>> Actually I had thought that the delay was to account for board routing
>> (wires) between the MAC and the PHY.
>> From your explanation it appears that the delay is to account for board
>> routing (wires) between the PHY and the RJ45 socket.
>
> The placement of the (delay) was not meant to be exact, but it was
> wrongly place anyway, so it should be between the MAC and PHY, always.
> This is why you see people either fixing the need for a delay by
> appropriately programming the PHY, or the MAC, or by just inserting a
> fixed delay on the PCB between the PHY and the MAC and programming no
> delays (or using the default values and hoping this works).
Thanks.
Your patch "[PATCH net-next 3/4] Documentation: net: phy: Add blurb about
RGMII" on the documentation makes it clear.
>>>
>>> This also seems reasonable to do, provided that the PHY is also properly
>>> configured not to add delays in both directions, and therefore assumes
>>> that the MAC does it.
>>>
>>> We have a fairly large problem with how RGMII delays are done in PHYLIB
>>> and Ethernet MAC drivers (or just in general), where we can't really
>>> intersect properly what a PHY is supporting (in terms of internal
>>> delays), and what the MAC supports either. One possible approach could
>>> be to update PHY drivers a list of PHY_INTERFACE_MODE_* that they
>>> support (ideally, even with normalized nanosecond delay values),
>>
>> Just to make sure I understood this, the DT would say something like:
>>
>> phy-connection-type = "rgmii-txid";
>> txid-delay-ns = <3>;
>>
>> For a 3ns TX delay, would that be good?
>
> That's one possibility, although, see below, some PHYs support
> sub-nanosecond values, but in general, that seems like a good
> representation. If the "txid-delay-ns" property is omitted, a standard
> 2ns delay is assumed.
Sounds good.
I did not see the "txid-delay-ns" property documented in your patches, if
it is not too late, maybe it could be "txid-delay-ps" using picoseconds as
unit, right?
>>> and
>>> then intersect that with the requested phy_interface_t during
>>> phy_{attach,connect} time, and feed this back to the MAC with a special
>>> error code/callback, so we could gracefully try to choose another
>>> PHY_INTERFACE_MODE_* value that the MAC supports....
>>>
>>> A larger problem is that a number of drivers have been deployed, and
>>> Device Trees, possibly with the meaning of "phy-mode" and
>>> "phy-connection-type" being from the MAC perspective, and not the PHY
>>> perspective *sigh*, good luck auditing those.
>>>
>>> So from there, here is possibly what we could do
>>>
>>> - submit a series of patches that update the PHYLIB documentation (there
>>> are other things missing here) and make it clear from which entity (PHY
>>> or MAC) does the delay apply to, document the "intersection" problem here
>>
>> I think documenting is necessary, thanks in advance!
>>
>> However, I'm wondering if there's a way to make this work in all cases.
>> Indeed, if we consider for example that TX delay is required, we have 4
>> cases:
>>
>> PHY | MAC | Who applies?
>> TXID supported | TXID supported | PHY
>> TXID supported | TXID not supported | PHY
>> TXID not supported | TXID supported | MAC
>> TXID not supported | TXID not supported | cannot be done
>>
>> That is basically what my patch:
>>
>> https://marc.info/?l=linux-netdev&m=147869658031783&w=2
>>
>> attempted to achieve. That would allow more combinations of MAC<->PHY to
>> work, right?
>
> Yes, indeed.
Just one thing, from your patch "[PATCH net-next 3/4] Documentation: net:
phy: Add blurb about RGMII" I have the impression that the 3rd option from
the table above, would be a little bit more complex to implement.
I will comment on the patch.
>> Nevertheless, I think we also need to keep in mind that most of this
>> discussion assumes the case where both, MAC and PHY have equal capabilities.
>> Could it happen that the PHY supports only 2ns delay, and the MAC only
>> 1ns delay?
>
> I doubt this exists at the MAC level what we should have is either a 2ns
> delay, in either RX or TX path, or nothing, because that's the value
> that results in shifting the data lines and the RX/TX lines by 90
> degrees at 125Mhz (1/125^6 = 8 ns, one quarter shift is 90 degrees =
> 2ns). The PHY may have a similar set of pre-programmed, fixed 2ns
> delays, but it is not uncommon to see 0.X ns resolution available:
>
> drivers/net/phy/mscc.c
> drivers/net/phy/dp83867.c w/ arch/arm/boot/dts/dra72-evm-revc.dts
>
> In these cases, if you end-up using a non 2ns delay, you are fixing a
> PCB problem more than an interoperability problem between your MAC and PHY.
I see, thanks.
>> Could it happen that the delay is bigger than what is supported by
>> either the PHY or MAC alone? maybe if combined it could work, for example
>> a 3ns delay required and the PHY supporting 2ns and the MAC 1ns, combined
>> it could work?
>
> I suppose such a thing would work yes, but it would be difficult to
> report correctly to the core PHYLIB how this can work considering the
> vast array of options available to introduce delays in that case:
> MAC-level, PHY-level, pinctrl/pad level and possibly at the PCB itself.
>
> Once we can't rely on the fixed 2ns delay to work, we are going to have
> people do various experiments until they can either measure what the
> right delay value is for the specific PCB, or they just found the value
> that happens to work. I don't think we can do much at that point from a
> core PHYLIB perspective other than tell the network driver that the PHY
> supports delay in either RX, TX or both directions, and have the MAC
> decide what to apply that makes sense here, considering that this is
> already kind of an exceptional situation to be in.
Fair enough.
And thanks again for documenting this.
^ permalink raw reply
* Adding a .platform_init callback to sdhci_arasan_ops
From: Adrian Hunter @ 2016-11-28 10:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <982d633b-e9c4-0f10-052b-e324f094d0f5@xilinx.com>
On 28/11/16 09:32, Michal Simek wrote:
> +Sai for Xilinx perspective.
>
> On 25.11.2016 16:24, Sebastian Frias wrote:
>> Hi,
>>
>> When using the Arasan SDHCI HW IP, there is a set of parameters called
>> "Hardware initialized registers"
>>
>> (Table 7, Section "Pin Signals", page 56 of Arasan "SD3.0/SDIO3.0/eMMC4.4
>> AHB Host Controller", revision 6.0 document)
>>
>> In some platforms those signals are connected to registers that need to
>> be programmed at some point for proper driver/HW initialisation.
>>
>> I found that the 'struct sdhci_ops' contains a '.platform_init' callback
>> that is called from within 'sdhci_pltfm_init', and that seems a good
>> candidate for a place to program those registers (*).
>>
>> Do you agree?
We already killed .platform_init
What is wrong with sdhci_arasan_probe()?
>>
>> Best regards,
>>
>> Sebastian
>>
>>
>> (*): This has been prototyped on 4.7 as working properly.
>> However, upstream commit:
>>
>> commit 3ea4666e8d429223fbb39c1dccee7599ef7657d5
>> Author: Douglas Anderson <dianders@chromium.org>
>> Date: Mon Jun 20 10:56:47 2016 -0700
>>
>> mmc: sdhci-of-arasan: Properly set corecfg_baseclkfreq on rk3399
>> ...
>>
>> could affect this solution because of the way the 'sdhci_arasan_of_match'
>> struct is used after that commit.
>>
>
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox