* [PATCH] ARM: dts: da850: specify the maximum bandwidth for tilcdc
From: Tomi Valkeinen @ 2016-11-28 7:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8829c208-0674-43c0-8449-ef764071583f@ti.com>
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.
But this 'max-bandwidth' does sound quite odd, as the it really should
be bytes, not pixels... Bad bindings again, which we just have to use.
Tomi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161128/12541df9/attachment.sig>
^ permalink raw reply
* [PATCH v3 00/12] Initial Tegra186 support
From: Thierry Reding @ 2016-11-28 7:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161126133927.GE20568@xo-6d-61-c0.localdomain>
On Sat, Nov 26, 2016 at 02:39:27PM +0100, Pavel Machek wrote:
> Hi!
>
> > From: Thierry Reding <treding@nvidia.com>
> >
> > Hi everyone,
> >
> > This is a set of patches to add initial support for Tegra186. It is
> > based on Joseph's patches but I rewrote some of the drivers to be a
> > little easier to comprehend and maintain (hopefully). I've also
> > included clock and reset drivers as a proof of concept.
>
> Is there any phone/tablet on the market with this chipset?
I'm not aware of any. The chip is primarily targetted at automotive
use-cases and probably not suited for phones or tablets.
Thierry
-------------- 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/602266c6/attachment-0001.sig>
^ permalink raw reply
* Adding a .platform_init callback to sdhci_arasan_ops
From: Michal Simek @ 2016-11-28 7:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d50dcd8a-2489-4e82-1dc7-13e93e38d5ff@laposte.net>
+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?
>
> 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 v2] clkdev: add devm_of_clk_get()
From: Kuninori Morimoto @ 2016-11-28 6:56 UTC (permalink / raw)
To: linux-arm-kernel
Current Linux has of_clk_get(), but doesn't have devm_of_clk_get().
This patch adds it. This is based on devm_clk_get()
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
---
v1 -> v2
- update git log
drivers/clk/clkdev.c | 26 ++++++++++++++++++++++++++
include/linux/clk.h | 7 +++++++
2 files changed, 33 insertions(+)
diff --git a/drivers/clk/clkdev.c b/drivers/clk/clkdev.c
index 89cc700..93a613b 100644
--- a/drivers/clk/clkdev.c
+++ b/drivers/clk/clkdev.c
@@ -55,6 +55,32 @@ struct clk *of_clk_get(struct device_node *np, int index)
}
EXPORT_SYMBOL(of_clk_get);
+static void devm_of_clk_release(struct device *dev, void *res)
+{
+ clk_put(*(struct clk **)res);
+}
+
+struct clk *devm_of_clk_get(struct device *dev,
+ struct device_node *np, int index)
+{
+ struct clk **ptr, *clk;
+
+ ptr = devres_alloc(devm_of_clk_release, sizeof(*ptr), GFP_KERNEL);
+ if (!ptr)
+ return ERR_PTR(-ENOMEM);
+
+ clk = of_clk_get(np, index);
+ if (!IS_ERR(clk)) {
+ *ptr = clk;
+ devres_add(dev, ptr);
+ } else {
+ devres_free(ptr);
+ }
+
+ return clk;
+}
+EXPORT_SYMBOL(devm_of_clk_get);
+
static struct clk *__of_clk_get_by_name(struct device_node *np,
const char *dev_id,
const char *name)
diff --git a/include/linux/clk.h b/include/linux/clk.h
index a89ba4e..33cd540 100644
--- a/include/linux/clk.h
+++ b/include/linux/clk.h
@@ -502,6 +502,8 @@ struct of_phandle_args;
#if defined(CONFIG_OF) && defined(CONFIG_COMMON_CLK)
struct clk *of_clk_get(struct device_node *np, int index);
+struct clk *devm_of_clk_get(struct device *dev,
+ struct device_node *np, int index);
struct clk *of_clk_get_by_name(struct device_node *np, const char *name);
struct clk *of_clk_get_from_provider(struct of_phandle_args *clkspec);
#else
@@ -509,6 +511,11 @@ static inline struct clk *of_clk_get(struct device_node *np, int index)
{
return ERR_PTR(-ENOENT);
}
+static inline struct clk *devm_of_clk_get(struct device *dev,
+ struct device_node *np, int index)
+{
+ return ERR_PTR(-ENOENT);
+}
static inline struct clk *of_clk_get_by_name(struct device_node *np,
const char *name)
{
--
1.9.1
^ permalink raw reply related
* [PATCH v2] ARM: dts: da850: add the mstpri and ddrctl nodes
From: Kevin Hilman @ 2016-11-28 6:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20fbc946-d56c-31a3-4ae7-cf61df96a3c3@ti.com>
On Wed, Nov 23, 2016 at 9:03 PM, Sekhar Nori <nsekhar@ti.com> wrote:
> On Thursday 24 November 2016 04:18 AM, David Lechner wrote:
>> On 11/23/2016 04:32 PM, Kevin Hilman wrote:
>>> David Lechner <david@lechnology.com> writes:
>>>
>>>> On 11/23/2016 04:27 AM, Bartosz Golaszewski wrote:
>>>>> 2016-11-22 23:23 GMT+01:00 David Lechner <david@lechnology.com>:
>>>>>> On 11/15/2016 05:00 AM, Bartosz Golaszewski wrote:
>>>>>>>
>>>>>>> Add the nodes for the MSTPRI configuration and DDR2/mDDR memory
>>>>>>> controller drivers to da850.dtsi.
>>>>>>>
>>>>>>> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
>>>>>>> ---
>>>>>>> v1 -> v2:
>>>>>>> - moved the priority controller node above the cfgchip node
>>>>>>> - renamed added nodes to better reflect their purpose
>>>>>>>
>>>>>>> arch/arm/boot/dts/da850.dtsi | 8 ++++++++
>>>>>>> 1 file changed, 8 insertions(+)
>>>>>>>
>>>>>>> diff --git a/arch/arm/boot/dts/da850.dtsi
>>>>>>> b/arch/arm/boot/dts/da850.dtsi
>>>>>>> index 1bb1f6d..412eec6 100644
>>>>>>> --- a/arch/arm/boot/dts/da850.dtsi
>>>>>>> +++ b/arch/arm/boot/dts/da850.dtsi
>>>>>>> @@ -210,6 +210,10 @@
>>>>>>> };
>>>>>>>
>>>>>>> };
>>>>>>> + prictrl: priority-controller at 14110 {
>>>>>>> + compatible = "ti,da850-mstpri";
>>>>>>> + reg = <0x14110 0x0c>;
>>>>>>
>>>>>>
>>>>>> I think we should add status = "disabled"; here and let boards opt in.
>>>>>>
>>>>>>> + };
>>>>>>> cfgchip: chip-controller at 1417c {
>>>>>>> compatible = "ti,da830-cfgchip", "syscon",
>>>>>>> "simple-mfd";
>>>>>>> reg = <0x1417c 0x14>;
>>>>>>> @@ -451,4 +455,8 @@
>>>>>>> 1 0 0x68000000 0x00008000>;
>>>>>>> status = "disabled";
>>>>>>> };
>>>>>>> + memctrl: memory-controller at b0000000 {
>>>>>>> + compatible = "ti,da850-ddr-controller";
>>>>>>> + reg = <0xb0000000 0xe8>;
>>>>>>
>>>>>>
>>>>>> same here. status = "disabled";
>>>>>>
>>>>>>> + };
>>>>>>> };
>>>>>>>
>>>>>
>>>>> Hi David,
>>>>>
>>>>> I did that initially[1][2] and it was rejected by Kevin[3] and
>>>>> Laurent[4].
>>>>>
>>>>> FYI this patch has already been queued by Sekhar.
>>>>
>>>> Thanks. I did not see those threads.
>>>>
>>>> FYI to maintainers, having these enabled by default causes error
>>>> messages in the kernel log for other boards that are not supported by
>>>> the drivers.
>>>
>>> Then the driver is too noisy and should be cleaned up.
>>>
>>>> Since there is only one board that is supported and soon
>>>> to be 2 that are not, I would rather have this disabled by default to
>>>> avoid the error messages.
>>>
>>> IMO, what exactly are the error messages? Sounds like the driver is
>>> being too verbose, and calling things errors that are not really errors.
>>
>> It is just one line per driver.
>>
>> dev_err(dev, "no master priorities defined for this board\n");
>>
>> and
>>
>> dev_err(dev, "no settings defined for this board\n");
>>
>>
>> Since "ti,da850-lcdk" is the only board supported in these drivers, all
>> other boards will see these error messages.
>
> Thats pretty bad. Sorry about that. The original justification for
> keeping them enabled all the time was that they are in-SoC modules with
> no external dependencies (like IO lines or voltage rails) so they can be
> enabled on all boards that use DA850. While that remains true, the
> configuration itself is board specific.
>
> I think the error messages are still useful, so instead of silencing
> them, I think we should go back to keeping these nodes disabled by
> default and enabling only on boards which have support for it in the driver.
I don't have a strong preference for the enabled/disabled by default,
but I think the error messages are not error messages. It seems
perfectly reasonable for boards to accept the reset (or bootloader)
configuration of these registers, and not consider that an error.
Kevin
^ permalink raw reply
* [PATCH] ARM: dts: da850: enable the memctrl and mstpri nodes per board
From: Sekhar Nori @ 2016-11-28 5:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479979884-9624-1-git-send-email-bgolaszewski@baylibre.com>
On Thursday 24 November 2016 03:01 PM, Bartosz Golaszewski wrote:
> Currently the memory controller and master priorities drivers are
> enabled in da850.dtsi. For boards for which there are no settings
> defined, this makes these drivers emit error messages.
>
> Disable the nodes in da850.dtsi and only enable them for da850-lcdk -
> the only board that currently needs them.
>
> Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Applied to v4.10/dt
Thanks,
Sekhar
^ permalink raw reply
* [PATCH] ARM: dts: da850-lcdk: Add ethernet0 alias to DT
From: Sekhar Nori @ 2016-11-28 5:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124143545.12817-1-fparent@baylibre.com>
On Thursday 24 November 2016 08:05 PM, Fabien Parent wrote:
> In order to avoid Linux generating a random mac address on every boot,
> add an ethernet0 alias that will allow u-boot to patch the dtb with
> the MAC address programmed into the EEPROM.
>
> Signed-off-by: Fabien Parent <fparent@baylibre.com>
Applied to v4.10/dt. Thanks!
Regards,
Sekhar
^ permalink raw reply
* [PATCH] ARM: dts: da850: specify the maximum bandwidth for tilcdc
From: Sekhar Nori @ 2016-11-28 5:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480088245-8368-1-git-send-email-bgolaszewski@baylibre.com>
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).
Thanks,
Sekhar
^ permalink raw reply
* [PATCH 2/2] input: touchscreen: sample averaging for imx6ul_tsc
From: Dmitry Torokhov @ 2016-11-28 4:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOMZO5CCtLdH9_5vGXfqg1rAizngVc_EWaoE+JfcfTrMmJT4xA@mail.gmail.com>
On Sun, Nov 27, 2016 at 10:39:10AM -0200, Fabio Estevam wrote:
> On Sun, Nov 27, 2016 at 5:44 AM, Guy Shapiro <guy.shapiro@mobi-wize.com> wrote:
> > The i.MX6UL internal touchscreen controller contains an option to
> > average upon samples. This feature reduces noise from the produced
> > touch locations.
> >
> > This patch adds sample averaging support to the imx6ul_tsc device
> > driver.
> >
> > Signed-off-by: Guy Shapiro <guy.shapiro@mobi-wize.com>
>
> Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Folded the binding patch into this one and applied, thank you.
--
Dmitry
^ permalink raw reply
* [PATCH 1/4] serial: core: Add LED trigger support
From: Florian Fainelli @ 2016-11-28 4:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161124081748.fx3xm5ww64ngn5it@pengutronix.de>
On 11/24/2016 12:17 AM, Sascha Hauer wrote:
> On Wed, Nov 23, 2016 at 10:57:13AM -0800, Florian Fainelli wrote:
>> On 11/23/2016 02:01 AM, Sascha Hauer wrote:
>>> With this patch the serial core provides LED triggers for RX and TX.
>>>
>>> As the serial core layer does not know when the hardware actually sends
>>> or receives characters, this needs help from the UART drivers.
>>
>> Looking at 8250, we call serial8250_tx_chars from __start_tx which is
>> called form the uart_ops::start_tx, for RX I sort of agree, since this
>> happens in interrupt handler. I suppose some drivers could actually
>> queue work but not do it right away though?
>
> RX is not the problem. When characters are received all drivers call
> tty_flip_buffer_push() which could be used for LED triggering (either
> directly or we replace the calls to tty_flip_buffer_push() with some
> wrapper function).
> The problem comes with TX. The serial core has a FIFO which gets
> characters from the tty layer. There is no function which the serial
> drivers could call to read from this FIFO, instead they have to open code
> this.
> Continuing with the 8250 driver serial8250_tx_chars() is not only called
> from __start_tx(), but also from the interrupt handler. Transmission
> works without the serial_core ever noticing.
>
>>
>>> The LED triggers are registered in uart_add_led_triggers() called from
>>> the UART drivers which want to support LED triggers. All the driver
>>> has to do then is to call uart_led_trigger_[tx|rx] to indicate
>>> activity.
>>
>> Could we somehow remedy the lack of knowledge from the core as whether
>> the HW sends/receives characters first before adding support for LED
>> triggers? It would be more generic and future proof to require UART
>> drivers to report to the core when they actually TX/RX, and then at the
>> core level, utilize that knowledge to perform the LED trigger.
>
> Maybe we could introduce a function to read from the TX FIFO. Having
> open coded this in each and every driver is not nice anyway.
Something like that could be nice to have yes.
>
>>
>> Side note: are you positive using drv->dev_name is robust enough on
>> systems with many different UART drivers, yet all of them being ttyS*?
>
> If we have different UART drivers, only one of them provides ttyS*, no?
> Other drivers will have to use another namespace.
I remember this was a problem a couple of years ago last I tried, with
the 8250 driver being actually preventing other drivers from using
ttyS*, but if you don't have 8250 taking over the low ttyS numbers, you
may run into a case where several drivers successfully register their
character devices under a ttyS* numbering scheme.
Whether this is hypothetical or not nowadays, it may be nicer to provide
a more uniquely distinct name like what dev_name() returns, or
ttyS*-driver-tx for instance?
--
Florian
^ permalink raw reply
* [bug report v4.8] fs/locks.c: kernel oops during posix lock stress test
From: Ming Lei @ 2016-11-28 3:10 UTC (permalink / raw)
To: linux-arm-kernel
Hi Guys,
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.
Thanks,
Ming
[1] kernel oops log
ubuntu at ubuntu:~/git/stress-ng$ ./stress-ng --lockf 128 --aggressive
stress-ng: info: [63828] defaulting to a 86400 second run per stressor
stress-ng: info: [63828] dispatching hogs: 128 lockf
stress-ng: info: [63828] cache allocate: default cache size: 16384K
[80659.799092] Unable to handle kernel NULL pointer dereference at
virtual address 00000030
[80659.807219] pgd = ffff81001f365800
[80659.810683] [00000030] *pgd=000001001a290003,
*pud=000001001a290003, *pmd=0000010fa07f0003, *pte=0000000000000000
[80659.821029] Internal error: Oops: 96000007 [#1] SMP
[80659.825901] Modules linked in:
[80659.828962] CPU: 15 PID: 63848 Comm: stress-ng-lockf Tainted: G
W 4.8.0 #167
[80659.837132] Hardware name: Cavium ThunderX CRB/To be filled by
O.E.M., BIOS 5.11 12/12/2012
[80659.845479] task: ffff81001ee78580 task.stack: ffff81001f798000
[80659.851402] PC is at posix_locks_conflict+0x94/0xc0
[80659.856282] LR is at posix_lock_inode+0x90/0x6b0
[80659.860896] pc : [<ffff00000828c694>] lr : [<ffff00000828cd90>]
pstate: a0000145
[80659.868285] sp : ffff81001f79bca0
[80659.871596] x29: ffff81001f79bca0 x28: ffff81001f798000
[80659.876915] x27: ffff800fdffbc160 x26: 0000000000000000
[80659.882234] x25: ffff800fd2da2b30 x24: ffff800fce927430
[80659.887551] x23: ffff800fce92d8f0 x22: ffff81001f79bd30
[80659.892869] x21: ffff800fd2da2b18 x20: fffffffffffffff8
[80659.898187] x19: ffff800fdffbc160 x18: 0000000000001140
[80659.903504] x17: 0000ffff8870a578 x16: ffff000008245768
[80659.908821] x15: 0000ffff888bc000 x14: 0000000000000000
[80659.914139] x13: 00000003e8000000 x12: 0000000000000018
[80659.919457] x11: 00000000000e6a17 x10: 00000000ffffffd0
[80659.924776] x9 : 0000000000000000 x8 : ffff800fce927500
[80659.930094] x7 : 0000000000000000 x6 : 000000000000007f
[80659.935413] x5 : 0000000000000080 x4 : ffff800fce927438
[80659.940729] x3 : ffff800fce927458 x2 : 00000000000026b9
[80659.946047] x1 : ffff81001f37f300 x0 : 0000000000000000
[80659.951363]
[80659.952851] Process stress-ng-lockf (pid: 63848, stack limit =
0xffff81001f798020)
[80659.960415] Stack: (0xffff81001f79bca0 to 0xffff81001f79c000)
[80659.966158] bca0: ffff81001f79bcc0 ffff00000828cd90
fffffffffffffff8 ffff800fa3a66568
[80659.973986] bcc0: ffff81001f79bd40 ffff00000828d5f0
ffff800f8185c700 ffff800fdffbc160
[80659.981812] bce0: 0000000000000006 0000000000000000
ffff81001f79bdd0 0000000000000006
[80659.989638] bd00: 0000000000000120 0000000000000019
ffff0000088b1000 ffff81001f798000
[80659.997465] bd20: ffff81001f79bd40 ffff000008403fec
ffff81001f79bd30 ffff81001f79bd30
[80660.005292] bd40: ffff81001f79bd70 ffff00000828d8bc
ffff800f8185c700 ffff800fdffbc160
[80660.013118] bd60: ffff800fdffbc1b8 ffff800f8185c700
ffff81001f79bde0 ffff00000828ef10
[80660.020944] bd80: ffff800f8185c700 0000000000000000
ffff800fdffbc160 ffff800fa3a66568
[80660.028770] bda0: 0000000000000006 0000000000000004
ffff81001f79bde0 ffff00000828ee14
[80660.036596] bdc0: ffff800f8185c700 00000000fffffff2
ffff800fdffbc160 ffff810ff99aae80
[80660.044423] bde0: ffff81001f79be70 ffff000008245b84
ffff800f8185c700 ffff800f8185c700
[80660.052249] be00: 0000000000000000 0000000000000006
0000ffffdad5d4b0 0000000000000004
[80660.060087] be20: 0000000000000120 000000000000003e
0000000000010001 0000000000000000
[80660.067916] be40: 0000000000000008 0000000000000000
0000000000010001 0000000000000000
[80660.075742] be60: 0000000000000008 0000000000000000
0000000000000000 ffff0000080836f0
[80660.083568] be80: 0000000000000000 00000000005c5000
ffffffffffffffff 0000ffff8870a3b8
[80660.091394] bea0: 0000000080000000 0000000000000015
0000000080000000 00000000005c5000
[80660.099220] bec0: 0000000000000004 0000000000000006
0000ffffdad5d4b0 00000000ffffff80
[80660.107046] bee0: 0000ffffdad5d490 0000000026c26373
000000000000176f 0000000000004650
[80660.114873] bf00: 0000000000000019 0000000000006536
00000000ffffffd0 00000000000e6a17
[80660.122698] bf20: 0000000000000018 00000003e8000000
0000000000000000 0000ffff888bc000
[80660.130524] bf40: 000000000048a170 0000ffff8870a578
0000000000001140 000000000000055f
[80660.138351] bf60: 00000000005c5000 0000000000000004
0000ffff879f9008 0000000000000000
[80660.146177] bf80: 0000000000000002 000000000048b530
2001000800400201 0000ffffdad60758
[80660.154004] bfa0: 000000000048b008 0000ffffdad5d390
0000ffff8870a518 0000ffffdad5d390
[80660.161830] bfc0: 0000ffff8870a3b8 0000000080000000
0000000000000004 0000000000000019
[80660.169656] bfe0: 0000000000000000 0000000000000000
0000000000000000 0000000000000000
[80660.177481] Call trace:
[80660.179928] Exception stack(0xffff81001f79bad0 to 0xffff81001f79bc00)
[80660.186365] bac0:
ffff800fdffbc160 0001000000000000
[80660.194192] bae0: ffff81001f79bca0 ffff00000828c694
ffff800fc0002c00 ffff81001ee78600
[80660.202017] bb00: ffff81001f79bb70 ffff00000820b57c
ffff800fcb2a6d88 ffff800fc0002c00
[80660.209843] bb20: 0000000000000001 ffff810008ddbf00
ffff81001f79bc30 ffff81001f79bc30
[80660.217670] bb40: 0000000000000000 ffff810fa0712be8
ffff800f81dfd680 ffff810fa0712be8
[80660.225496] bb60: 0000000000000001 ffff810008ddbf00
0000000000000000 ffff81001f37f300
[80660.233322] bb80: 00000000000026b9 ffff800fce927458
ffff800fce927438 0000000000000080
[80660.241148] bba0: 000000000000007f 0000000000000000
ffff800fce927500 0000000000000000
[80660.248974] bbc0: 00000000ffffffd0 00000000000e6a17
0000000000000018 00000003e8000000
[80660.256800] bbe0: 0000000000000000 0000ffff888bc000
ffff000008245768 0000ffff8870a578
[80660.264636] [<ffff00000828c694>] posix_locks_conflict+0x94/0xc0
[80660.270559] [<ffff00000828cd90>] posix_lock_inode+0x90/0x6b0
[80660.276220] [<ffff00000828d5f0>] vfs_lock_file+0x68/0x78
[80660.281537] [<ffff00000828d8bc>] do_lock_file_wait+0x54/0xe0
[80660.287199] [<ffff00000828ef10>] fcntl_setlk+0x1c0/0x308
[80660.292513] [<ffff000008245b84>] SyS_fcntl+0x41c/0x5b8
[80660.297653] [<ffff0000080836f0>] el0_svc_naked+0x24/0x28
[80660.302961] Code: a8c27bfd d65f03c0 d503201f f9401e61 (f9401e80)
[80660.309188] ---[ end trace aa50050684d3a3fe ]---
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stress-ng-more-aggressive.patch
Type: text/x-patch
Size: 4864 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161128/9c079139/attachment-0001.bin>
^ permalink raw reply
* [PATCH v2 0/7] stmmac: dwmac-meson8b: configurable RGMII TX delay
From: David Miller @ 2016-11-28 1:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161125130156.17879-1-martin.blumenstingl@googlemail.com>
From: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Date: Fri, 25 Nov 2016 14:01:49 +0100
> Currently the dwmac-meson8b stmmac glue driver uses a hardcoded 1/4
> cycle TX clock delay. This seems to work fine for many boards (for
> example Odroid-C2 or Amlogic's reference boards) but there are some
> others where TX traffic is simply broken.
> There are probably multiple reasons why it's working on some boards
> while it's broken on others:
> - some of Amlogic's reference boards are using a Micrel PHY
> - hardware circuit design
> - maybe more...
The ARM arch file changes do not apply cleanly to net-next, you probably
want to merge them via the ARM tree instead of mine, and respin this series
to be without the .dts file changes.
^ permalink raw reply
* [PATCH 1/1] net: macb: fix the RX queue reset in macb_rx()
From: David Miller @ 2016-11-28 1:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <fd8131cbe6c0546b2b8ee35bcaac5e7eb1a1647f.1480063339.git.cyrille.pitchen@atmel.com>
From: Cyrille Pitchen <cyrille.pitchen@atmel.com>
Date: Fri, 25 Nov 2016 09:49:32 +0100
> On macb only (not gem), when a RX queue corruption was detected from
> macb_rx(), the RX queue was reset: during this process the RX ring
> buffer descriptor was initialized by macb_init_rx_ring() but we forgot
> to also set bp->rx_tail to 0.
>
> Indeed, when processing the received frames, bp->rx_tail provides the
> macb driver with the index in the RX ring buffer of the next buffer to
> process. So when the whole ring buffer is reset we must also reset
> bp->rx_tail so the driver is synchronized again with the hardware.
>
> Since macb_init_rx_ring() is called from many locations, currently from
> macb_rx() and macb_init_rings(), we'd rather add the "bp->rx_tail = 0;"
> line inside macb_init_rx_ring() than add the very same line after each
> call of this function.
>
> Without this fix, the rx queue is not reset properly to recover from
> queue corruption and connection drop may occur.
>
> Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
> Fixes: 9ba723b081a2 ("net: macb: remove BUG_ON() and reset the queue to handle RX errors")
This doesn't apply cleanly to the 'net' tree, where
RX_RING_SIZE is used instead of bp->rx_ring_size. It seems
you generated this against net-next, however you didn't say
that either in your Subject line nor the commit message.
As a bug fix this should be targetted at 'net'.
^ permalink raw reply
* [PATCH v2 2/3] ARM: dts: sunxi: add support for Orange Pi Zero board
From: André Przywara @ 2016-11-28 0:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5373671480239408@web31m.yandex.ru>
On 27/11/16 09:36, Icenowy Zheng wrote:
Hi,
> 22.11.2016, 00:26, "Icenowy Zheng" <icenowy@aosc.xyz>:
>> Orange Pi Zero is a board that came with the new Allwinner H2+ SoC.
>>
>> Add a device tree file for it.
>>
>> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>> ---
>> Changes since v2:
>> - Use generic pinconf binding instead of legacy allwinner pinctrl binding.
>> - removed uart3, which is not accessible on Orange Pi Zero.
>> - Removed sun8i-h2plus.dtsi and make Orange Pi Zero dts directly include
>> sun8i-h3.dtsi.
>> - Removed allwinner,sun8i-h3 compatible.
>>
>> arch/arm/boot/dts/Makefile | 1 +
>> arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts | 137 +++++++++++++++++++++++
>> 2 files changed, 138 insertions(+)
>> create mode 100644 arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 802a10d..51a1dd7 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -834,6 +834,7 @@ dtb-$(CONFIG_MACH_SUN8I) += \
>> sun8i-a33-sinlinx-sina33.dtb \
>> sun8i-a83t-allwinner-h8homlet-v2.dtb \
>> sun8i-a83t-cubietruck-plus.dtb \
>> + sun8i-h2plus-orangepi-zero.dtb \
>> sun8i-h3-bananapi-m2-plus.dtb \
>> sun8i-h3-nanopi-neo.dtb \
>> sun8i-h3-orangepi-2.dtb \
>> diff --git a/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
>> new file mode 100644
>> index 0000000..b428e47
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/sun8i-h2plus-orangepi-zero.dts
>> @@ -0,0 +1,137 @@
>> +/*
>> + * Copyright (C) 2016 Icenowy Zheng <icenowy@aosc.xyz>
>> + *
>> + * Based on sun8i-h3-orangepi-one.dts, which is:
>> + * Copyright (C) 2016 Hans de Goede <hdegoede@redhat.com>
>> + *
>> + * This file is dual-licensed: you can use it either under the terms
>> + * of the GPL or the X11 license, at your option. Note that this dual
>> + * licensing only applies to this file, and not this project as a
>> + * whole.
>> + *
>> + * a) This file is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License as
>> + * published by the Free Software Foundation; either version 2 of the
>> + * License, or (at your option) any later version.
>> + *
>> + * This file 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.
>> + *
>> + * Or, alternatively,
>> + *
>> + * b) Permission is hereby granted, free of charge, to any person
>> + * obtaining a copy of this software and associated documentation
>> + * files (the "Software"), to deal in the Software without
>> + * restriction, including without limitation the rights to use,
>> + * copy, modify, merge, publish, distribute, sublicense, and/or
>> + * sell copies of the Software, and to permit persons to whom the
>> + * Software is furnished to do so, subject to the following
>> + * conditions:
>> + *
>> + * The above copyright notice and this permission notice shall be
>> + * included in all copies or substantial portions of the Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + * OTHER DEALINGS IN THE SOFTWARE.
>> + */
>> +
>> +/dts-v1/;
>> +#include "sun8i-h3.dtsi"
>> +#include "sunxi-common-regulators.dtsi"
>> +
>> +#include <dt-bindings/gpio/gpio.h>
>> +#include <dt-bindings/input/input.h>
>> +#include <dt-bindings/pinctrl/sun4i-a10.h>
>> +
>> +/ {
>> + model = "Xunlong Orange Pi Zero";
>> + compatible = "xunlong,orangepi-zero", "allwinner,sun8i-h2plus";
>> +
>> + aliases {
>> + serial0 = &uart0;
>> + };
>> +
>> + chosen {
>> + stdout-path = "serial0:115200n8";
>> + };
>> +
>> + leds {
>> + compatible = "gpio-leds";
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&leds_opi0>, <&leds_r_opi0>;
>> +
>> + pwr_led {
>> + label = "orangepi:green:pwr";
>> + gpios = <&r_pio 0 10 GPIO_ACTIVE_HIGH>;
>> + default-state = "on";
>> + };
>> +
>> + status_led {
>> + label = "orangepi:red:status";
>> + gpios = <&pio 0 17 GPIO_ACTIVE_HIGH>;
>> + };
>> + };
>> +};
>> +
>> +&ehci1 {
>> + status = "okay";
>> +};
>> +
>> +&mmc0 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
>> + vmmc-supply = <®_vcc3v3>;
>> + bus-width = <4>;
>> + cd-gpios = <&pio 5 6 GPIO_ACTIVE_HIGH>; /* PF6 */
>> + cd-inverted;
>> + status = "okay";
>> +};
>> +
>> +&ohci1 {
>> + status = "okay";
>> +};
>> +
>> +&pio {
>> + leds_opi0: led_pins at 0 {
>> + pins = "PA17";
>> + function = "gpio_out";
>> + };
>> +};
>> +
>> +&r_pio {
>> + leds_r_opi0: led_pins at 0 {
>> + pins = "PL10";
>> + function = "gpio_out";
>> + };
>> +};
>> +
>> +&uart0 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&uart0_pins_a>;
>> + status = "okay";
>> +};
>> +
>> +&uart1 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&uart1_pins>;
>> + status = "disabled";
>> +};
>> +
>> +&uart2 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&uart2_pins>;
>> + status = "disabled";
>> +};
>> +
>> +&usbphy {
>> + /* USB VBUS is always on */
>> + status = "okay";
>> +};
>
> Something more interesting happened.
>
> Xunlong made a add-on board for Orange Pi Zero, which exposes the two USB Controllers exported at expansion bus as USB Type-A connectors.
>
> Also it exposes a analog A/V jack and a microphone.
>
> Should I enable {e,o}hci{2.3} in the device tree?
Actually we should do this regardless of this extension board. The USB
pins are not multiplexed and are exposed on user accessible pins (just
not soldered, but that's a detail), so I think they qualify for DT
enablement. And even if a user can't use them, it doesn't hurt to have
them (since they are not multiplexed).
Cheers,
Andre.
^ permalink raw reply
* [PATCH 2/2] net: dsa: mv88e6xxx: Add 88E6176 device tree support
From: Andrew Lunn @ 2016-11-27 23:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e5d45b55-a4c1-3b5e-0bdc-a5e340b072d0@suse.de>
> Try to see it from my perspective: I see that some vf610 device I don't
> have (found via `git grep marvell,mv88e6` or so) uses
> "marvell,mv88e6085". I then assume it has that device on board. How
> would I know it doesn't? Same for the other boards you mention.
>
> Unfortunately some of your replies are slightly cryptic. Had you simply
> replied 'please just use "marvell,mv88e6085" instead', it would've been
> much more clear what you want. (Same for extending the subject instead
> of just pointing to some FAQ.)
By reading the FAQ you have learnt more than me saying put the correct
tree in the subject line. By asking you to explain why you need a
compatible string, i'm trying to make you think, look at the code and
understand it. In the future, you might think and understand the code
before posting a patch, and then we all save time.
> So are you okay with patch 1/2 documenting the compatible? Then we could
> drop 2/2 and use "marvell,mv88e6176", "marvell,mv88e6085" instead of
> just the latter. Or would you rather drop both and keep the actual chip
> a comment?
A comment only please.
Thanks
Andrew
^ permalink raw reply
* [PATCH 2/2] net: dsa: mv88e6xxx: Add 88E6176 device tree support
From: Andreas Färber @ 2016-11-27 22:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161127220846.GH13318@lunn.ch>
Andrew,
Am 27.11.2016 um 23:08 schrieb Andrew Lunn:
>>> This driver already supports nearly 30 different Marvell switch
>>> models. Please document why the marvell,mv88e6176 is special and why
>>> it needs its own compatible string when the others don't.
>>
>> I don't understand.
>
> Think about what i said. Why does the 6176 need its own compatible
> string, when the two 6352s and the 6165 on the zii-devel-b don't have
> one? And the DIR 665 has a 6171, which does not have a compatible
> string of its own. The clearfog actually has a 6176, and it seems to
> work fine without a compatible string.
>
>> You as driver author should know that the .data pointer is vital to your
>> driver
>
> Exactly, so if i ask why is it needed, maybe you should stop and think
> for a while.
>
>> you even recently accepted another model that conflicted with
>> my patch.
>
> And think about that also, and you will find the 6390 family, who's
> first device is 6190, is not compatible with the 6085, and so needs a
> different compatible string.
Try to see it from my perspective: I see that some vf610 device I don't
have (found via `git grep marvell,mv88e6` or so) uses
"marvell,mv88e6085". I then assume it has that device on board. How
would I know it doesn't? Same for the other boards you mention.
Unfortunately some of your replies are slightly cryptic. Had you simply
replied 'please just use "marvell,mv88e6085" instead', it would've been
much more clear what you want. (Same for extending the subject instead
of just pointing to some FAQ.)
So are you okay with patch 1/2 documenting the compatible? Then we could
drop 2/2 and use "marvell,mv88e6176", "marvell,mv88e6085" instead of
just the latter. Or would you rather drop both and keep the actual chip
a comment?
Regards,
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 0/5] Meson GXL and GXM USB support
From: Martin Blumenstingl @ 2016-11-27 22:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161126145635.24488-1-martin.blumenstingl@googlemail.com>
Hello Kishon,
On Sat, Nov 26, 2016 at 3:56 PM, Martin Blumenstingl
<martin.blumenstingl@googlemail.com> wrote:
> USB support on GXL and GXM differs a lot from Meson8b and GXBB:
> The most obvious change is that GXL and GXM now have one dwc3
> controller and one dwc2 controller (instead of two dwc2 controllers).
> With that there are also new USB PHYs.
>
> Due to lack of hardware I was only able to test this on a board with
> GXM, but as far as I understand the hardware my preparations should be
> correct (so it should also work on GXL).
>
> dwc2 will probably stay unused on most GXM devices since it's limited
> to device mode via some dwc2 hardware configuration register.
>
> dwc3 is probably used on all devices, even if there is more than just
> one USB port. dwc3 has a built-in USB2 hub - on GXL this hub has two
> ports enabled, while on GXM there are three ports enabled (see below
> for lsusb output). There are no USB3 ports enabled in the dwc3 hardware
> configuration, meaning that the SoC is limited to high-speed mode.
> On my GXM device the dwc3 hardware configuration forces it into "host
> only" mode.
>
> The SoCs contain two PHY blocks: one USB3 PHY and up to four USB2 PHYs
> (on GXM there are only three enabled, but the registers should support
> up to four).
> The USB3 PHY also handles the OTG interrupts, but since dwc3's hardware
> configuration enforces "host only" mode I was not able to test this. It
> simply takes care of an interrupt and then notifies all related PHYs
> about the new mode.
> The USB2 PHY block is a bit different: I created one PHY driver which
> spans all "PHY ports" because the handling is a bit tricky. It turns
> out that for each available USB port in dwc3's hub the corresponding
> PHY must be enabled (even if there is no physical port - in my case
> port 3 is not connected to anything, but disabling the PHY breaks
> ports 1 and 2 as well).
> I decided not not pass the USB2 PHYs directly to dwc3 due to three
> reasons: 1. the USB3 PHY (which holds a reference to all relevant
> USB2 PHY ports) controls the mode of the USB2 PHY ports (since both
> are used with the same controller and thus it makes sense to keep the
> mode consistent across all ports) 2. the dwc3 driver does not support
> passing multiple USB2 PHYs (only one USB2 and one USB3 PHY can be
> passed to it) 3. it is similar to how the vendor reference driver
> manages the PHYs. Please note that this coupling is not a fixed, this
> is all configurable via devicetree (so if the third USB2 PHY has to
> be passed two the dwc2 controller then this is still possible by
> just moving on PHY reference in the .dts).
after not staring at my own code for 24 hours I realized this:
(I went through quite a few iterations before getting these drivers to work)
I'm basically re-modelling an "USB PHY hub" with my USB3 PHY driver
(there's one "upstream" PHY interface which is passed to dwc3 and
multiple downstream PHYs, each for one port on dwc3's internal hub).
With this approach I could split each of the the USB2s into separate
nodes again (instead of one devicetree node with #phy-cells = <1>) as
the USB3 PHY is taking care of that special "we have to enable all
ports or no port will be usable".
We could go even one step further: why implement this in the Meson GXL
specific PHY driver - why not implement a generic "phy-hub" driver
(which would be valid whenever the PHY controller has to manage
multiple PHYs at once, but wants to keep them all in a consistent
state).
The devicetree could look like this:
usb2_phy_hub: phy at 0 {
compatible = "phy-hub";
phys = <&other_phy1>, <&other_phy 2>;
};
&dwc3 {
phys = <&usb2_phy_hub>, <&usb3_phy0>;
phy-names = "usb2-phy", "usb3-phy";
};
The generic phy-hub driver would then implement all phy_ops callbacks
and pass then to each of it's downstream PHYs.
That's just what came into my head - please let me know what you think
of this or share your ideas on how to approach this!
> The coupling of the USB2 and USB3 PHYs is the reason why I sent the
> two drivers in one patch, even though they are handling different IP
> blocks (different registers, etc.).
>
> Unfortunately there are no datasheets available for any of these PHYs.
> Both drivers were written by reading the reference drivers provided by
> Amlogic and analyzing the registers on the kernel that was shipped with
> my board.
>
> As a last note: the dwc3 driver currently only explicitly enables the
> first USB port "DWC3_GUSB2PHYCFG(0)" in the internal hub. The hardware
> seems to enable the other two (DWC3_GUSB2PHYCFG(1) and
> DWC3_GUSB2PHYCFG(2)) automatically. I will ask the dwc3 maintainers if
> changes to dwc3 are desired any how these should look like, but for now
> it's working fine even without changes there.
>
> lsusb output on GXM for the dwc3 hub:
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> ...
> Hub Port Status:
> Port 1: 0000.0100 power
> Port 2: 0000.0100 power
> Port 3: 0000.0100 power
>
> NOTE: The devicetree changes depend on my previous series:
> "[PATCH 0/2] minor GXL and GXM improvements" - see [0]
>
> NOTE2: This series depends on an upstream dwc3/xhci-plat DMA fix
> (special thanks to Arnd Bergmann and Sriram Dash for fixing that):
> "[PATCH v5 0/6] inherit dma configuration from parent dev" - see [1]
>
> I have a tree with all dependencies applied available at [2] if
> someone wants a quick way to test this (I don't take any responsibility
> if anything explodes though).
>
> [0] http://lists.infradead.org/pipermail/linux-amlogic/2016-November/001665.html
> [1] http://marc.info/?l=linux-usb&m=147938307209685&w=2
> [2] https://github.com/xdarklight/linux/commits/meson-gx-integration-4.10-20161126
>
> Martin Blumenstingl (5):
> Documentation: dt-bindings: Add documentation for Meson GXL USB2/3
> PHYs
> phy: meson: add USB2 and USB3 PHY support for Meson GXL
> arm64: dts: meson-gxl: add USB support
> ARM64: dts: meson-gxm: add GXM specific USB configuration
> ARM64: dts: meson-gx-p23x-q20x: enable USB on P23x and Q20x boards
>
> .../devicetree/bindings/phy/meson-gxl-usb2-phy.txt | 25 ++
> .../devicetree/bindings/phy/meson-gxl-usb3-phy.txt | 27 ++
> .../arm64/boot/dts/amlogic/meson-gx-p23x-q20x.dtsi | 12 +
> arch/arm64/boot/dts/amlogic/meson-gxl.dtsi | 49 +++
> .../arm64/boot/dts/amlogic/meson-gxm-s912-q200.dts | 17 +
> arch/arm64/boot/dts/amlogic/meson-gxm.dtsi | 10 +
> drivers/phy/Kconfig | 13 +
> drivers/phy/Makefile | 2 +
> drivers/phy/phy-meson-gxl-usb2.c | 374 ++++++++++++++++++++
> drivers/phy/phy-meson-gxl-usb3.c | 377 +++++++++++++++++++++
> 10 files changed, 906 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/phy/meson-gxl-usb2-phy.txt
> create mode 100644 Documentation/devicetree/bindings/phy/meson-gxl-usb3-phy.txt
> create mode 100644 drivers/phy/phy-meson-gxl-usb2.c
> create mode 100644 drivers/phy/phy-meson-gxl-usb3.c
>
> --
> 2.10.2
>
^ permalink raw reply
* [PATCH] ARM: dts: mvebu: Fix armada-385-turris-omnia stdout-path
From: Uwe Kleine-König @ 2016-11-27 22:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0f51c7a1-6d52-3e3e-edfe-e7b10917ecab@suse.de>
Hello,
On Sun, Nov 27, 2016 at 11:14:37PM +0100, Andreas F?rber wrote:
> Am 27.11.2016 um 22:25 schrieb Uwe Kleine-K?nig:
> > On Sun, Nov 27, 2016 at 08:37:24PM +0100, Andreas F?rber wrote:
> >> Specify the baudrate.
> >>
> >> Fixes: 26ca8b52d6e1 ("ARM: dts: add support for Turris Omnia")
> >> Cc: Uwe Kleine-K?nig <uwe@kleine-koenig.org>
> >> Signed-off-by: Andreas F?rber <afaerber@suse.de>
> >
> > You said with plain &uart0 the kernel uses a wrong baud rate? That's
> > strange. For me it works and I think it's the intended behaviour to
> > dermine the baud rate setup by the bootloader and use this.
>
> IIRC the 8250 driver defaults to 9600n8 if unspecified.
>
> Kernel tested: 4.9.0-rc2-next-20161028-00010-g4fb44d9-dirty
>
> Maybe you used some console= argument overriding it?
Yes, you're right.
> > I'd prefer it this way over hard coding the baud rate.
> >
> >> arch/arm/boot/dts/armada-385-turris-omnia.dts | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> >> index f53cb8b73610..2eff012287d4 100644
> >> --- a/arch/arm/boot/dts/armada-385-turris-omnia.dts
> >> +++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
> >> @@ -52,7 +52,7 @@
> >> compatible = "cznic,turris-omnia", "marvell,armada385", "marvell,armada380";
> >>
> >> chosen {
> >> - stdout-path = &uart0;
> >> + stdout-path = "serial0:115200n8";
> >> };
> >>
> >> memory {
> >
> > This has the downside to depend on the alias. Not sure this is
> > considered modern. An alternative would be:
> >
> > stdout-path = "/soc/internal-regs/serial at 12000:115200n8";
>
> Please don't unroll the path I'm trying to abstract elsewhere.
Yeah, specifying the path isn't nice.
> Like I said, the "serialX:115200n8" syntax is what all other Armada 38x
> boards use:
This isn't a reason to not think about better alternatives. An if
something like:
stdout-path = &uart0 + ":115200n8";
would be possible, I'd definitely prefer it over "serial0:115200n8".
> git grep stdout-path -- arch/arm/boot/dts/ | grep armada-38
> arch/arm/boot/dts/armada-385-db-ap.dts: stdout-path = "serial1:115200n8";
> arch/arm/boot/dts/armada-385-linksys.dtsi: stdout-path =
> "serial0:115200n8";
> arch/arm/boot/dts/armada-388-clearfog.dts: stdout-path =
> "serial0:115200n8";
> arch/arm/boot/dts/armada-388-db.dts: stdout-path = "serial0:115200n8";
> arch/arm/boot/dts/armada-388-gp.dts: stdout-path = "serial0:115200n8";
> arch/arm/boot/dts/armada-388-rd.dts: stdout-path = "serial0:115200n8";
>
> The alias is needed to reliably determine the tty device number and is
> set "globally" in armada-38x.dtsi, so why is it a problem to rely on?
AFAIK aliases are seen as (still necessary) evil by the dt people. So if
you can stop making use of them, that would be nice.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH] ARM: dts: mvebu: Fix armada-385-turris-omnia stdout-path
From: Andreas Färber @ 2016-11-27 22:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161127212528.wmqbwciz5ltnfws3@pengutronix.de>
Am 27.11.2016 um 22:25 schrieb Uwe Kleine-K?nig:
> On Sun, Nov 27, 2016 at 08:37:24PM +0100, Andreas F?rber wrote:
>> Specify the baudrate.
>>
>> Fixes: 26ca8b52d6e1 ("ARM: dts: add support for Turris Omnia")
>> Cc: Uwe Kleine-K?nig <uwe@kleine-koenig.org>
>> Signed-off-by: Andreas F?rber <afaerber@suse.de>
>
> You said with plain &uart0 the kernel uses a wrong baud rate? That's
> strange. For me it works and I think it's the intended behaviour to
> dermine the baud rate setup by the bootloader and use this.
IIRC the 8250 driver defaults to 9600n8 if unspecified.
Kernel tested: 4.9.0-rc2-next-20161028-00010-g4fb44d9-dirty
Maybe you used some console= argument overriding it?
> I'd prefer it this way over hard coding the baud rate.
>
>> arch/arm/boot/dts/armada-385-turris-omnia.dts | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/boot/dts/armada-385-turris-omnia.dts b/arch/arm/boot/dts/armada-385-turris-omnia.dts
>> index f53cb8b73610..2eff012287d4 100644
>> --- a/arch/arm/boot/dts/armada-385-turris-omnia.dts
>> +++ b/arch/arm/boot/dts/armada-385-turris-omnia.dts
>> @@ -52,7 +52,7 @@
>> compatible = "cznic,turris-omnia", "marvell,armada385", "marvell,armada380";
>>
>> chosen {
>> - stdout-path = &uart0;
>> + stdout-path = "serial0:115200n8";
>> };
>>
>> memory {
>
> This has the downside to depend on the alias. Not sure this is
> considered modern. An alternative would be:
>
> stdout-path = "/soc/internal-regs/serial at 12000:115200n8";
Please don't unroll the path I'm trying to abstract elsewhere.
Like I said, the "serialX:115200n8" syntax is what all other Armada 38x
boards use:
git grep stdout-path -- arch/arm/boot/dts/ | grep armada-38
arch/arm/boot/dts/armada-385-db-ap.dts: stdout-path = "serial1:115200n8";
arch/arm/boot/dts/armada-385-linksys.dtsi: stdout-path =
"serial0:115200n8";
arch/arm/boot/dts/armada-388-clearfog.dts: stdout-path =
"serial0:115200n8";
arch/arm/boot/dts/armada-388-db.dts: stdout-path = "serial0:115200n8";
arch/arm/boot/dts/armada-388-gp.dts: stdout-path = "serial0:115200n8";
arch/arm/boot/dts/armada-388-rd.dts: stdout-path = "serial0:115200n8";
The alias is needed to reliably determine the tty device number and is
set "globally" in armada-38x.dtsi, so why is it a problem to rely on?
Regards,
Andreas
>
> (maybe there even exists syntactic sugar to express this using &uart0?)
--
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 2/2] net: dsa: mv88e6xxx: Add 88E6176 device tree support
From: Andrew Lunn @ 2016-11-27 22:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <9500470d-09c3-3ecb-994b-3d108bffc99e@suse.de>
> > This driver already supports nearly 30 different Marvell switch
> > models. Please document why the marvell,mv88e6176 is special and why
> > it needs its own compatible string when the others don't.
>
> I don't understand.
Think about what i said. Why does the 6176 need its own compatible
string, when the two 6352s and the 6165 on the zii-devel-b don't have
one? And the DIR 665 has a 6171, which does not have a compatible
string of its own. The clearfog actually has a 6176, and it seems to
work fine without a compatible string.
> You as driver author should know that the .data pointer is vital to your
> driver
Exactly, so if i ask why is it needed, maybe you should stop and think
for a while.
> you even recently accepted another model that conflicted with
> my patch.
And think about that also, and you will find the 6390 family, who's
first device is 6190, is not compatible with the 6085, and so needs a
different compatible string.
Andrew
^ permalink raw reply
* [PATCH 2/2] net: dsa: mv88e6xxx: Add 88E6176 device tree support
From: Andreas Färber @ 2016-11-27 21:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161127212709.GD13318@lunn.ch>
Am 27.11.2016 um 22:27 schrieb Andrew Lunn:
> On Sun, Nov 27, 2016 at 09:57:59PM +0100, Andreas F?rber wrote:
>> This model is found on the Turris Omnia.
>
> This driver already supports nearly 30 different Marvell switch
> models. Please document why the marvell,mv88e6176 is special and why
> it needs its own compatible string when the others don't.
I don't understand.
The commit message above already points out for which device this is
(and you also know from the LAKML thread).
You as driver author should know that the .data pointer is vital to your
driver - you even recently accepted another model that conflicted with
my patch. So are you arguing for a ", which uses a Device Tree for
booting" half-sentence here?
The others not having an entry simply means no one needed them yet.
And any Turris Omnia side changes need to go through the mvebu tree.
Regards,
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] mv88e6xxx: Fix mv88e6xxx_g1_irq_free() interrupt count
From: Andrew Lunn @ 2016-11-27 21:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ff0d121a-0ecb-8af7-af11-cf94df31639c@suse.de>
On Sun, Nov 27, 2016 at 10:32:41PM +0100, Andreas F?rber wrote:
> Hi Andrew,
>
> Am 27.11.2016 um 22:22 schrieb Andrew Lunn:
> > On Sun, Nov 27, 2016 at 09:43:44PM +0100, Andreas F?rber wrote:
> >> mv88e6xxx_g1_irq_setup() sets up chip->g1_irq.nirqs interrupt mappings,
> >> so free the same amount. This will be 8 or 9 in practice, less than 16.
> >
> > Hi Andreas
> >
> > The patch is correct, but please read
> > Documentation/networking/netdev-FAQ.txt
> > and then resubmit the patch.
>
> Do you mean --subject-prefix="PATCH net-next"
Yep.
Thanks
Andrew
^ permalink raw reply
* [PATCH] ARM: dts: vf610-zii-dev-rev-b: Add missing newline
From: Andrew Lunn @ 2016-11-27 21:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <e9336935-264e-5d1c-656e-a48f89d1b015@suse.de>
On Sun, Nov 27, 2016 at 10:30:54PM +0100, Andreas F?rber wrote:
> Hi,
>
> Am 27.11.2016 um 22:17 schrieb Andrew Lunn:
> > On Sun, Nov 27, 2016 at 08:54:44PM +0100, Andreas F?rber wrote:
> >> Found while reviewing Marvell dsa bindings usage.
> >
> > Hi Andreas
> >
> > It is good practice to put the maintainer you expect to accept the
> > patch on the To: line. You have at least two different maintainers on
> > Cc: so it is currently ambiguous. And these lists can be high volume,
> > so without a copy in the maintainers inbox, patches can be overlooked.
>
> As a vf610 DT patch with LAKML in To I am expecting it to be handled by
> Shawn or anyone from the NXP/ARM side.
So please have Shawn as To:
The patch you are fixing went through Dave Miller, who is also on Cc:,
hence the ambiguity.
Andrew
^ permalink raw reply
* [PATCH v2] MAINTAINERS: Add device tree bindings to mv88e6xx section
From: Andrew Lunn @ 2016-11-27 21:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1480280850-10409-1-git-send-email-afaerber@suse.de>
On Sun, Nov 27, 2016 at 10:07:30PM +0100, Andreas F?rber wrote:
> Also include the netdev list for convenience, as done elsewhere.
Please indicate which maintainer you expect to accept this. And if that
is David Miller, please fix the Subject: line.
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
> Signed-off-by: Andreas F?rber <afaerber@suse.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [PATCH] mv88e6xxx: Fix mv88e6xxx_g1_irq_free() interrupt count
From: Andreas Färber @ 2016-11-27 21:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161127212256.GC13318@lunn.ch>
Hi Andrew,
Am 27.11.2016 um 22:22 schrieb Andrew Lunn:
> On Sun, Nov 27, 2016 at 09:43:44PM +0100, Andreas F?rber wrote:
>> mv88e6xxx_g1_irq_setup() sets up chip->g1_irq.nirqs interrupt mappings,
>> so free the same amount. This will be 8 or 9 in practice, less than 16.
>
> Hi Andreas
>
> The patch is correct, but please read
> Documentation/networking/netdev-FAQ.txt
> and then resubmit the patch.
Do you mean --subject-prefix="PATCH net-next" or something else?
Thanks,
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
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