Bug#855017: [PATCH] ARM: dts: kirkwood: Fix SATA pinmux-ing for TS419
Hello, On Mon, 20 Feb 2017 17:22:38 +, Ben Hutchings wrote: > You mean, define additional pinmux nodes and override the pinctrl-0 > property of ? More like this: Yes, exactly. Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Bug#855017: [PATCH] ARM: dts: kirkwood: Fix SATA pinmux-ing for TS419
Hello, On Mon, 20 Feb 2017 16:40:25 +, Ben Hutchings wrote: > That is precisely what I intended. 20-23 are used by the second > Ethernet port. The old board code doesn't assign 4 or 5 at all. Then I believe it would be more explicit to have separate pin muxing configurations for SATA on this board. Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
Bug#855017: [PATCH] ARM: dts: kirkwood: Fix SATA pinmux-ing for TS419
Hello,
Adding in Cc all the maintainers of the Kirkwood platforms.
On Sat, 18 Feb 2017 00:32:51 +, Ben Hutchings wrote:
> +_sata0 {
> + marvell,pins = "mpp15";
> +};
> +
> +_sata1 {
> + marvell,pins = "mpp16";
> +};
This is not only muxing mpp15 as sata0 and mpp16 as sata1, but also
removes the muxing of sata0/sata1 pins described in kirkwood-6282.dtsi:
pmx_sata0: pmx-sata0 {
marvell,pins = "mpp5", "mpp21", "mpp23";
marvell,function = "sata0";
};
pmx_sata1: pmx-sata1 {
marvell,pins = "mpp4", "mpp20", "mpp22";
marvell,function = "sata1";
};
So it means that MPP 4, 5, 20, 21, 22 and 23 will no longer be muxed as
sata0/sata1. Is this really what you want?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
Bug#714959: linux-image-3.2.0-4-kirkwood mdraid array fails to assemble b/c drives are not yet ready (sata_mv)
Dear Andrew Lunn, On Wed, 26 Mar 2014 14:55:11 +0100, Andrew Lunn wrote: I _guess_ the real problem here is the power supply. It cannot supply enough power to get all the drives spinning if they all start at the same time. Many of the multi-bay NAS boxes have GPIO lines which are used to individually power up each driver in a staggered way. The QNAP kernel patch is doing something similar. However in its current form it cannot be accepted. This delay needs to be made conditional and only applied on hardware with a weak power supply. I will take a look at the code and see how the platform can pass a flag to the driver that it needs to stagger port initialization. The Marvell LSP code also has some changes into the core ATA to implement staggered disk spin-up. I believe they are probably visible in the publicly visible LSP code at https://github.com/yellowback/ubuntu-precise-armadaxp/, but I haven't checked in detail. If you're interested, I can probably dig the LSP patch that does that. Thomas -- Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140326151702.69a38c16@skate
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
Hello,
On Fri, 7 Jun 2013 19:26:49 +0100, luke.leighton wrote:
Have you noticed that it is already the case in mainline?
i knew there was a little bit, but not the extent of the commits.
Then you could probably use a bit of your time to read the kernel
commit logs rather than writing hundreds of e-mails, no?
My colleague Maxime Ripard (Cc'ed)
maxime: we need to talk :)
please tell me in 4 or 5 sentences what you've managed to do so far,
expanding a little on what thomas says below, more specifically what
it achieves and/or allows rather than technically what it does
(suitable for managers and directors in other words), and what plans
you'd like to see happen.
Maxime will reply to this in more details, but I believe the status is:
* Interrupt controller is working.
* Clock drivers are working.
* Pinctrl is working.
* GPIO is working.
* Timer is working.
* UART is working
* Watchdog is on its way (patches posted)
* Ethernet is on its way (patches posted)
* I2C is on its way (patches posted)
Cubieboard (A10), Hackberry (A10), Mini XPlus (A10) And OLinuxino (A13)
are supported.
See arch/arm/boot/dts/sun{4,5}i* for a good overview.
All in mainline, completely Device Tree based.
great. which version did it first hit, i.e. what will the first
signs of this be when allwinner begin doing git pulls?
The very first support landed in 3.8.
So isn't this entire discussion completely moot?
no because it's totally in isolation from allwinner. i need to give
them a heads-up, and get them involved, giving them specific
incentives [which nobody's yet given!!] for following a particular
path [or paths] yet to be recommended.
You really believe you're more important than you really are, I'd say.
My colleague Maxime is in contact with Allwinner, he has regular
discussion with them, started reviewing some of the kernel code they're
writing, has received datasheets from them, and evaluation boards.
So this work is definitely not done in isolation from Allwinner, and
they have received much more than an heads-up from Maxime.
The mainline support
for sunxi has already started since 6 months or so, and has been Device
Tree based from day one.
to clarify: the *community-driven* mainline support for sunxi. ok -
which chips? sun3i (ARM9), sun4i (Cortex A8), sun5i, sun6i and sun7i
(Dual-Core Cortex A7)? which ones are in?
So far, A10 and A13. Maxime has received a A31 evaluation board from
Allwinner very recently, and also A10S and A20 boards. I suppose he
will be working on those fairly and posting the corresponding patches
fairly soon.
In other words, it looks like you've started an entire discussion about
the mainline support for Allwinner SoCs without having a look at what
git log tells you... Which by itself is a very good indicator that
you're probably not the best interlocutor for Allwinner as far as
mainline development is concerned.
Best regards,
Thomas Petazzoni
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130607205940.4816fed5@skate
Re: [Arm-netbook] getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
Dear Tomasz Figa, On Thu, 06 Jun 2013 02:01:14 +0200, Tomasz Figa wrote: I don't see any other solution here than moving all the Allwinner code to DT (as it has been suggested in this thread several times already), as this is the only hardware description method supported by ARM Linux. Have you noticed that it is already the case in mainline? My colleague Maxime Ripard (Cc'ed) is the maintainer of the mainline Allwinner sunxi effort. It already supports a number of boards, has a pinctrl driver, a GPIO driver, serial port is working, network is working, I2C is working. All in mainline, completely Device Tree based. So isn't this entire discussion completely moot? The mainline support for sunxi has already started since 6 months or so, and has been Device Tree based from day one. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130606112723.71ddd70c@skate
Re: getting allwinner SoC support upstream (was Re: Uploading linux (3.9.4-1))
Hello, On Wed, 5 Jun 2013 16:48:27 -0400, jonsm...@gmail.com wrote: fex covers *eevvveeerrthng* - right from flipping the multiplexing for all 3 SD/MMC cards so that you can pretend that SD0 is SD2 and you can specify *different* GPIOs for each to say which is You can do all of this in device tree too. If the exact syntax doesn't exist you can use 'allwinner,' prefixes on the node names. Also check out pinctrl so that it doesn't get reinvented. Are people looking at the mainline source code? There is already a pinctrl driver for sunxi platforms (i.e Allwinner SoCs), it's at drivers/pinctrl/pinctrl-sunxi.c, and it's DT-based and allows to describe the pin muxing in the Device Tree. Cc'ing Maxime Ripard, who is the mach-sunxi maintainer in the mainline kernel. Best regards, Thomas -- Thomas Petazzoni, Free Electrons Kernel, drivers, real-time and embedded Linux development, consulting, training and support. http://free-electrons.com -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130606112948.7cd444a4@skate
