* Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol
From: Sudeep Holla @ 2016-11-08 16:08 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Sudeep Holla, Neil Armstrong, devicetree, linux-kernel,
Olof Johansson, linux-amlogic, linux-arm-kernel
In-Reply-To: <20161108154038.GS1041@n2100.armlinux.org.uk>
On 08/11/16 15:40, Russell King - ARM Linux wrote:
> On Tue, Nov 08, 2016 at 03:11:07PM +0000, Sudeep Holla wrote:
>> On 08/11/16 14:51, Russell King - ARM Linux wrote:
>>> On Wed, Nov 02, 2016 at 10:52:03PM -0600, Sudeep Holla wrote:
>>>> This is minor rework of the series[1] from Neil Armstrong's to support
>>>> legacy SCPI protocol to make DT bindings more generic and move out all
>>>> the platform specific bindings out of the generic binding document.
>>>
>>> Is this what would be in my HBI0282B Juno?
>>>
>>
>> No, it's one on the AmLogic Meson GXBB platform. Juno never supported
>> that except that old firmware use it internally. By that I mean some
>> version of trusted firmware used legacy SCPI but they are generally
>> bundled together in fip, so you should not see any issue with upgrade.
>
> I was wondering whether it'd work with my existing 1st September 2014
> version of the trusted firmware. I've pretty much come to the
> conclusion that there's no way I can run the later firmware on this
> hardware.
>
No, we should be able to fix it. It's just some weird configuration
that has triggered this. Generally people just replace entire tarball
into uSD and hence it is not tested very well for such cases.
>> I am currently trying to run Linaro 16.10 release, I don't see any issue
>> except network boot from UEFI which is known and reported.
>
> Interesting - maybe the hardware is different then?
>
No, we have seen issues in past especially UEFI.
>> I will go through your logs in detail and try to replicate your issue.
>> I assume you have tried replacing the entry contents of the uSD with the
>> release. I will start with that now.
>
> I haven't wiped it and copied the entire contents of the zip file over.
> I instead backed up the old board.txt and images.txt files, and copied
> the HBI0282B directories on top of the others.
>
> This correctly causes all the various components to be updated when the
> board boots, updating the MBB BIOS, iofpga, and reprogramming the NOR
> flash with the updated images. I even diff'd what was on the uSD card
> and what was supplied in the zip file.
>
> That's one state I tested: it also allowed me to edit the board.txt and
> similar to wind back to what I have now on the board - which is all the
> old versions of the firmware except for the MBB BIOS.
>
> Anyway, I've wiped the uSD, and copied the contents of the 16.10 release
> over:
>
[...]
> Memory Allocation 0x00000004 0xFE07B000 - 0xFE826FFF
> Memory Allocation 0x00000004 0xFE03B000 - 0xFE07AFFF
> Memory Allocation 0x00000003 0xFE03B000 - 0xFE07AFFF
> FV Hob 0xE0000000 - 0xE00EFFFF
> FV Hob 0xFE07B000 - 0xFE8253BF
> FV2 Hob 0xFE07B000 - 0xFE8253BF
>
> which looks more hopeful... except it stops there.
>
Ah that's good, some progress.
> As it contains a zero sized Image and .dtb files, I tried copying my
> Image and .dtb over, and also copied my original config.txt (only
> change is AUTORUN: FALSE). It still doesn't appear to boot beyond
> this point.
>
I will focus on this and see what's happening. I have issue with network
on my setup with debug build and Linaro guys are not seeing it. I revert
to release build of UEFI for that. Anyways one suggestion I have right
now is to erase the second partition of NOR flash where the old UEFI
config is placed and it could be conflicting with the new UEFI image.
Cmd> flash
Switching on main power...
PMIC RAM configuration (pms_v105.bin)...
IOFPGA config: PASSED
Enabling usb remote...
Flash> ERASERANGE 0x0BFC0000 0x0BFF0000
I will looking into that further.
--
Regards,
Sudeep
^ permalink raw reply
* Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol
From: Russell King - ARM Linux @ 2016-11-08 16:06 UTC (permalink / raw)
To: Sudeep Holla, Philippe Robin
Cc: devicetree, Neil Armstrong, linux-kernel, Olof Johansson,
linux-amlogic, linux-arm-kernel
In-Reply-To: <20161108154038.GS1041@n2100.armlinux.org.uk>
On Tue, Nov 08, 2016 at 03:40:38PM +0000, Russell King - ARM Linux wrote:
> As it contains a zero sized Image and .dtb files, I tried copying my
> Image and .dtb over, and also copied my original config.txt (only
> change is AUTORUN: FALSE). It still doesn't appear to boot beyond
> this point.
Well, it seems that I can't even go back to my original set of firmware
as UEFI has stopped working:
NOTICE: Booting Trusted Firmware
NOTICE: BL1: v1.0(release):14b6608
NOTICE: BL1: Built : 14:15:51, Sep 1 2014
NOTICE: BL1: Booting BL2
NOTICE: BL2: v1.0(release):14b6608
NOTICE: BL2: Built : 14:15:51, Sep 1 2014
NOTICE: BL1: Booting BL3-1
NOTICE: BL3-1: v1.0(release):14b6608
NOTICE: BL3-1: Built : 14:15:53, Sep 1 2014
UEFI firmware (version v2.1 built at 14:41:56 on Oct 23 2014)
Warning: Fail to load FDT file 'juno.dtb'.
and UEFI is the most unfriendly thing going - the "boot manager" thing
doesn't let you view the configuration:
[1] Linux from NOR Flash
[2] Shell
[3] Boot Manager
Start: 3
[1] Add Boot Device Entry
[2] Update Boot Device Entry
[3] Remove Boot Device Entry
[4] Reorder Boot Device Entries
[5] Update FDT path
[6] Set Boot Timeout
[7] Return to main menu
Choice:
and dropping into the shell... well, I've no idea how to get a listing
of what it thinks is in the NOR device (or even how to refer to the
NOR device.) "devices" shows nothing that's even remotely English.
So... my Juno is now useless to me - nothing more than a paperweight,
so this is now _high_ priority.
--
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
* Re: [PATCH v4 8/8] iio: envelope-detector: ADC driver based on a DAC and a comparator
From: Thomas Gleixner @ 2016-11-08 15:59 UTC (permalink / raw)
To: Peter Rosin
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA, Jonathan Cameron,
Hartmut Knaack, Lars-Peter Clausen, Peter Meerwald-Stadler,
Rob Herring, Mark Rutland, Daniel Baluta, Slawomir Stepien,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1478606339-31253-9-git-send-email-peda-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
On Tue, 8 Nov 2016, Peter Rosin wrote:
> +/*
> + * The envelope_detector_comp_latch function works together with the compare
> + * interrupt service routine below (envelope_detector_comp_isr) as a latch
> + * (one-bit memory) for if the interrupt has triggered since last calling
> + * this function.
> + * The ..._comp_isr function disables the interrupt so that the cpu does not
> + * need to service a possible interrupt flood from the comparator when no-one
> + * cares anyway, and this ..._comp_latch function reenables them again if
> + * needed.
> + */
> +static int envelope_detector_comp_latch(struct envelope *env)
> +{
> + int comp;
> +
> + spin_lock_irq(&env->comp_lock);
> + comp = env->comp;
> + env->comp = 0;
> + spin_unlock_irq(&env->comp_lock);
> +
> + if (!comp)
> + return 0;
> +
> + /*
> + * The irq was disabled, and is reenabled just now.
> + * But there might have been a pending irq that
> + * happened while the irq was disabled that fires
> + * just as the irq is reenabled. That is not what
> + * is desired.
> + */
> + enable_irq(env->comp_irq);
> +
> + /* So, synchronize this possibly pending irq... */
> + synchronize_irq(env->comp_irq);
> +
> + /* ...and redo the whole dance. */
> + spin_lock_irq(&env->comp_lock);
> + comp = env->comp;
> + env->comp = 0;
> + spin_unlock_irq(&env->comp_lock);
> +
> + if (comp)
> + enable_irq(env->comp_irq);
So you need that whole dance including the delayed work because you cannot
call iio_write_channel_raw() from hard interrupt context, right?
So you might just register a threaded interrupt handler, which should make
this whole thing way simpler.
devm_request_threaded_irq(dev, irq, NULL, your_isr, IRQF_ONESHOT, ...);
The core will mask the interrupt line until the threaded handler is
finished. The threaded handler is invoked with preemption enabled, so you
can sleep there as long as you want. So you can do everything in your
handler and the above dance is just not required.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 3/3] dt-bindings: i2c: pxa: Update the documentation for the Armada 3700
From: Gregory CLEMENT @ 2016-11-08 15:55 UTC (permalink / raw)
To: Romain Perier
Cc: Wolfram Sang, linux-i2c, devicetree, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Thomas Petazzoni, Nadav Haklai, Omri Itach,
Shadi Ammouri, Yahuda Yitschak, Hanna Hawa, Neta Zur Hershkovits,
Igal Liberman, Marcin Wojtas
In-Reply-To: <20161108151506.1131-4-romain.perier@free-electrons.com>
Hi Romain,
On mar., nov. 08 2016, Romain Perier <romain.perier@free-electrons.com> wrote:
> This commit documents the compatible string to have the compatibility for
> the I2C unit found in the Armada 3700.
>
> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
> ---
> Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
> index 12b78ac..b1b995c 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
> @@ -7,6 +7,7 @@ Required properties :
> compatible processor, e.g. pxa168, pxa910, mmp2, mmp3.
> For the pxa2xx/pxa3xx, an additional node "mrvl,pxa-i2c" is required
> as shown in the example below.
> + For the Armada 3700, the compatible should be "marvell,armada-3700".
You meant "marvell,armada-3700-i2c" I guess.
Gregory
> Recommended properties :
>
> --
> 2.9.3
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 1/3] ipmi/bt-bmc: change compatible node to 'aspeed,ast2400-ibt-bmc'
From: Cédric Le Goater @ 2016-11-08 15:52 UTC (permalink / raw)
To: Arnd Bergmann
Cc: devicetree, Corey Minyard, Benjamin Herrenschmidt, Rob Herring,
Joel Stanley, openipmi-developer, linux-arm-kernel
In-Reply-To: <2368736.y6FyG1ESuP@wuerfel>
On 11/07/2016 02:02 PM, Arnd Bergmann wrote:
> On Wednesday, November 2, 2016 3:28:01 PM CET Cédric Le Goater wrote:
>> On 11/02/2016 02:56 PM, Joel Stanley wrote:
>>> On Wed, Nov 2, 2016 at 11:45 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>>>> On Wednesday 02 November 2016, Cédric Le Goater wrote:
>>>>> The Aspeed SoCs have two BT interfaces : one is IPMI compliant and the
>>>>> other is H8S/2168 compliant.
>>>>>
>>>>> The current ipmi/bt-bmc driver implements the IPMI version and we
>>>>> should reflect its nature in the compatible node name using
>>>>> 'aspeed,ast2400-ibt-bmc' instead of 'aspeed,ast2400-bt-bmc'. The
>>>>> latter should be used for a H8S interface driver if it is implemented
>>>>> one day.
>>>>>
>>>>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>>>>
>>>> We generally try to avoid changing the compatible strings after the
>>>> fact, but it's probably ok in this case.
>>
>> As the device tree changes are not merged yet, we thought we had some
>> more time to fine tune the naming.
>
> Ok, I see. No problem then.
>
>>>> I don't understand who decides which of the two interfaces is used:
>>>> is it the same register set that can be driven by either one or the
>>>> other driver, or do you expect to have two drivers that can both
>>>> be active in the same system and talk to different hardware once
>>>> you get there?
>>>
>>> It's the second case. The H8S BT has a different register layout so it
>>> would require a different driver.
>>
>> yes.
>>
>>> We don't yet have a driver for the other BT device, but there was
>>> recent talk of using it as an alternate (non-ipmi channel) between the
>>> BMC and the host. Before that discussion I wasn't aware that the H8S
>>> BT existed. I suggested we fix this up before it hits a final release.
>>>
>>> Cédric, do you think ast2400-ibt-bmc or ast2400-ipmi-bt-bmc does a
>>> better job of describing the hardware here?
>>
>> The specs refer to the two interfaces as BT (non IPMI) and iBT (IPMI).
>> I think we can keep the same naming.
>
> Ok
>
>>> While we're modifying the binding, should we add a compat string for
>>> the ast2500?
>>
>> Well, if the change in this patch is fine for all, may be we can add
>> the ast2500 compat string in a followup patch ?
>
> Sounds good to me.
OK. So, how do we proceed with this patch ? Who would include it in its
tree ?
Thanks,
C.
^ permalink raw reply
* Re: [PATCH 2/3] arm64: dts: marvell: Add I2C definitions for the Armada 3700
From: Gregory CLEMENT @ 2016-11-08 15:52 UTC (permalink / raw)
To: Wolfram Sang, Romain Perier
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Thomas Petazzoni, Nadav Haklai, Omri Itach,
Shadi Ammouri, Yahuda Yitschak, Hanna Hawa, Neta Zur Hershkovits,
Igal Liberman, Marcin Wojtas
In-Reply-To: <20161108151506.1131-3-romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Hi Romain and Wolfram,
On mar., nov. 08 2016, Romain Perier <romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> The Armada 3700 has two i2c bus interface units, this commit adds the
> definitions of the corresponding device nodes. It also enables the node
> on the development board for this SoC.
>
> Signed-off-by: Romain Perier <romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Acked-by: Gregory CLEMENT <gregory.clement-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
This patch is OK for me but I would like to apply it myself on
mvebu/dt. Indeed Thomas Petazzoni pointed that I made a typo on the
peripheral clock label: nb_perih_clk instead of nb_periph_clk. I would
like to fix it and by applying this patch I will avoid a merge conflict
or worse a mismatch with the label name.
Wolfram, once you will be OK with the patch 1 and 3, I will apply the
patch 2.
Thanks,
Gregory
> ---
> arch/arm64/boot/dts/marvell/armada-3720-db.dts | 4 ++++
> arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 18 ++++++++++++++++++
> 2 files changed, 22 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/marvell/armada-3720-db.dts b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
> index 1372e9a6..16d84af 100644
> --- a/arch/arm64/boot/dts/marvell/armada-3720-db.dts
> +++ b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
> @@ -62,6 +62,10 @@
> };
> };
>
> +&i2c0 {
> + status = "okay";
> +};
> +
> /* CON3 */
> &sata {
> status = "okay";
> diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> index c476253..bf2d73d 100644
> --- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> @@ -98,6 +98,24 @@
> /* 32M internal register @ 0xd000_0000 */
> ranges = <0x0 0x0 0xd0000000 0x2000000>;
>
> + i2c0: i2c@11000 {
> + compatible = "marvell,armada-3700-i2c";
> + reg = <0x11000 0x24>;
> + clocks = <&nb_perih_clk 10>;
> + interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
> + mrvl,i2c-fast-mode;
> + status = "disabled";
> + };
> +
> + i2c1: i2c@11080 {
> + compatible = "marvell,armada-3700-i2c";
> + reg = <0x11080 0x24>;
> + clocks = <&nb_perih_clk 9>;
> + interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
> + mrvl,i2c-fast-mode;
> + status = "disabled";
> + };
> +
> uart0: serial@12000 {
> compatible = "marvell,armada-3700-uart";
> reg = <0x12000 0x400>;
> --
> 2.9.3
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] pinctrl: tegra: Add driver to configure voltage and power of io pads
From: Laxman Dewangan @ 2016-11-08 15:48 UTC (permalink / raw)
To: Linus Walleij
Cc: thierry.reding@gmail.com, Stephen Warren, Rob Herring,
Mark Rutland, Jon Hunter, Masahiro Yamada,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <CACRpkdZWc1jC2QzYq4ffT6YbhfbsEBbKtajMXuexA8MvJEPPEw@mail.gmail.com>
On Tuesday 08 November 2016 09:16 PM, Linus Walleij wrote:
> On Tue, Nov 8, 2016 at 2:35 PM, Laxman Dewangan <ldewangan@nvidia.com> wrote:
>
>> There is two types of configuration in given platform, the IO voltage does
>> not get change (fixed in given platform) and in some of cases, get change
>> dynamically like SDIO3.0 where the voltage switches to 3.3V and 1.8V.
>>
>> Yes, it can be integrated with the regulator handle and then it can call the
>> required configurations through notifier and regulator_get_voltage().
>> But I think it is too much complex for the static configurations. This
>> mandate also to populate the regulator handle and all power tree.
>>
>> The simple way for static configuration (case where voltage does not get
>> change), just take the power tree IO voltage from DT and configure the IO
>> pad control register.
>>
>> For dynamic case, there is some sequence need to be followed based on
>> voltage direction change (towards lower or towards higher) for the voltage
>> change and the IO pad voltage configuration and it is simple to do it from
>> client driver.
> The devicetree should describe the platform.
>
> Adding this custom attribute does not describe the platform very
> well since the dependency to the corresponding regulator is hidden.
>
> The point of device tree is not as much to make things simple as
> to describe the world properly.
>
> So to me it is simple: use regulators and phandles.
>
> It might require a bit of upfront coding but the result will look
> much nicer.
Oops, I asked same clarification when replying the Thierry's comment.
Got answer now.. only via regulator support.
I am going to support the IO pad voltage control with regulator only.
No custom attribute for this.
However, for support for low-power will be same as this patch.
^ permalink raw reply
* Re: [v15, 3/7] powerpc/fsl: move mpc85xx.h to include/linux/fsl
From: Arnd Bergmann @ 2016-11-08 15:47 UTC (permalink / raw)
To: Y.B. Lu
Cc: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org,
linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org, Scott Wood,
Mark Rutland, Greg Kroah-Hartman, X.B. Xie, M.H. Lian,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Qiang Zhao,
Russell King, Bhupesh Sharma, Joerg Roedel, Claudiu Manoil,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Rob Herring
In-Reply-To: <DB6PR0401MB25366BC8FF59C68E2823245EF8A60-2mNvjAGDOPkZcyyZo0JLBI3W/0Ik+aLCnBOFsp37pqbUKgpGm//BTAC/G2K4zDHf@public.gmane.org>
On Tuesday, November 8, 2016 6:49:51 AM CET Y.B. Lu wrote:
> Hi Arnd,
>
>
> > -----Original Message-----
> > From: Arnd Bergmann [mailto:arnd-r2nGTMty4D4@public.gmane.org]
> > Sent: Tuesday, November 08, 2016 5:20 AM
> > To: Y.B. Lu
> > Cc: linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org; linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> > ulf.hansson-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org; Scott Wood; Mark Rutland; Greg Kroah-Hartman; X.B.
> > Xie; M.H. Lian; linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-clk-u79uwXL29TY76Z2rM5mHXA@public.gmane.org;
> > Qiang Zhao; Russell King; Bhupesh Sharma; Joerg Roedel; Claudiu Manoil;
> > devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Rob Herring; Santosh Shilimkar; linux-arm-
> > kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org; netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; linux-
> > kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; Leo Li; iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org; Kumar
> > Gala
> > Subject: Re: [v15, 3/7] powerpc/fsl: move mpc85xx.h to include/linux/fsl
> >
> > On Monday, October 31, 2016 9:35:33 AM CET Y.B. Lu wrote:
> > > >
> > > > I don't see any of the contents of this header referenced by the soc
> > > > driver any more. I think you can just drop this patch.
> > > >
> > >
> > > [Lu Yangbo-B47093] This header file was included by guts.c.
> > > The guts driver used macro SVR_MAJ/SVR_MIN for calculation.
> > >
> > > This header file was for powerpc arch before. And this patch is to
> > > made it as common header file for both ARM and PPC.
> > > Sooner or later this is needed.
> >
> > Let's discuss it once we actually need the header then, ok?
>
> [Lu Yangbo-B47093] As I said, this header file was included by guts.c in patch 4.
Ah sorry, I misread your earlier reply, thinking you meant a potential
future patch.
> The guts driver used macro SVR_MAJ/SVR_MIN for calculation which were
> defined in this header file.
> Did you suggest we dropped this patch and just calculated them in driver?
That is probably nicer here: there is not that much value in sharing
the two one-line macro definitions, and the driver already hardcodes
the numeric per-chip IDs that make up most of the header file.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] pinctrl: tegra: Add driver to configure voltage and power of io pads
From: Linus Walleij @ 2016-11-08 15:46 UTC (permalink / raw)
To: Laxman Dewangan
Cc: thierry.reding@gmail.com, Stephen Warren, Rob Herring,
Mark Rutland, Jon Hunter, Masahiro Yamada,
linux-gpio@vger.kernel.org, devicetree@vger.kernel.org,
linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <5821D49E.2070308@nvidia.com>
On Tue, Nov 8, 2016 at 2:35 PM, Laxman Dewangan <ldewangan@nvidia.com> wrote:
> There is two types of configuration in given platform, the IO voltage does
> not get change (fixed in given platform) and in some of cases, get change
> dynamically like SDIO3.0 where the voltage switches to 3.3V and 1.8V.
>
> Yes, it can be integrated with the regulator handle and then it can call the
> required configurations through notifier and regulator_get_voltage().
> But I think it is too much complex for the static configurations. This
> mandate also to populate the regulator handle and all power tree.
>
> The simple way for static configuration (case where voltage does not get
> change), just take the power tree IO voltage from DT and configure the IO
> pad control register.
>
> For dynamic case, there is some sequence need to be followed based on
> voltage direction change (towards lower or towards higher) for the voltage
> change and the IO pad voltage configuration and it is simple to do it from
> client driver.
The devicetree should describe the platform.
Adding this custom attribute does not describe the platform very
well since the dependency to the corresponding regulator is hidden.
The point of device tree is not as much to make things simple as
to describe the world properly.
So to me it is simple: use regulators and phandles.
It might require a bit of upfront coding but the result will look
much nicer.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 2/2] pinctrl: tegra: Add driver to configure voltage and power of io pads
From: Laxman Dewangan @ 2016-11-08 15:45 UTC (permalink / raw)
To: Thierry Reding
Cc: Linus Walleij, Stephen Warren, Rob Herring, Mark Rutland,
Jon Hunter, Masahiro Yamada, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-tegra@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20161108144211.GA2244@ulmo.ba.sec>
On Tuesday 08 November 2016 08:12 PM, Thierry Reding wrote:
> * PGP Signed by an unknown key
>
> On Tue, Nov 08, 2016 at 07:05:26PM +0530, Laxman Dewangan wrote:
>>
>> Yes, it can be integrated with the regulator handle and then it can call the
>> required configurations through notifier and regulator_get_voltage().
>> But I think it is too much complex for the static configurations. This
>> mandate also to populate the regulator handle and all power tree.
> It looks as if regulator notifiers should be able to support whatever
> use-cases we may have (I suspect that we really only need pre- and post-
> voltage-change notifications.
>
Yes, we have pre/post and abort notification from regulator.
REGULATOR_EVENT_PRE_VOLTAGE_CHANGE,
REGULATOR_EVENT_ABORT_VOLTAGE_CHANGE,
REGULATOR_EVENT_VOLTAGE_CHANGE,
So it can be done dynamically.
As the notification is atomic context, we need to support atomic context
of pmc register configurations.
>> The simple way for static configuration (case where voltage does not get
>> change), just take the power tree IO voltage from DT and configure the IO
>> pad control register.
> For static configurations where we have a regulator along with a pinmux
> setting for the I/O voltage we could potentially run into issues where
> both settings don't match. How would we handle that?
As a process, we are generating the IO pad control DT configuration from
the customer pinmux spreadsheet. So there is data population by hardware
(system eng) team and SW just use the auto-generated dtsi file in SW.
This avoided the error/mistake created by the SW engineer.
>
>> For dynamic case, there is some sequence need to be followed based on
>> voltage direction change (towards lower or towards higher) for the voltage
>> change and the IO pad voltage configuration and it is simple to do it from
>> client driver.
> Are patches available for this? It'd be useful to know how this will end
> up being used in order to come up with the best solution.
>
> In general I think it's good to send a complete series of patches, even
> if it's long and spans multiple subsystems. As it is it's difficult for
> anyone else (myself included) to understand where this is headed, which
> makes it more complicated than necessary to get at the final solution.
The dynamic setting is used by mmc driver and it is handled by mmc team.
They are waiting for framework/infrastructure to be available for their
patches.
However, in downstream, we have all these implemented. In downstram we
have pad control driver but instead of new framework, we decided to do
it through pinctrl framework.
So if you look for mmc driver in downstream, you can get the actual
code about usage.
However, for clarity, here is sequence:
1. Voltage from 3.3V to 1.8V
ret = regulator_set_voltage(regulator, 1800000, 1800000);
if (!ret)
ret = padctrl_set_voltage(padctrl, 1800000);
2. Voltage from 1.8V to 3.3V
ret = padctrl_set_voltage(padctrl, 3300000);
if (!ret)
ret = regulator_set_voltage(regulator, 3300000, 3300000);
With pinctrl framework, the APIs will be
pinctrl_lookup_state(pinctrl, "io-pad-3v3");
or
pinctrl_lookup_state(pinctrl, "io-pad-1v8");
The static setting is doen during initialization of the driver.
>>
>> I like to have both approach, through pinmux DT and also from regulator. So
>> based on the platform, if regulator supported then populate required
>> properties in DT for regulator else go on standard pinmux DT way (for
>> non-regulator cases).
> Again, it would be best to see this in actual use. Right now it's not
> clear that we'll even have both cases. Implementing both approaches will
> mean potentially unused code.
We can have the only one say regulator approach then it will be
mandatory to have regulator nodes for all vdd-io so that io-pads are
configured properly.
In the probe, it will get regulator and if found the get_voltage and
configure pmc.
I am thinking about supporting IO pad configuration(static) in case we
do not have regulator enabled/up in platform and want to set IO pads
manually from DT.
> On another note: in my experience you seldom need both cases, since the
> dynamic configuration is the hard one, and the static configuration will
> usually be a special case of the dynamic configuration.
>
>
Cases will be with regulator support available or not.
So if we donot want to support the cases, where actual regualator
support is not available then we will not need to set IO pads voltage
via DT framework.
However, we will still needs low-power support from pinctrl framework.
^ permalink raw reply
* Re: [PATCH 1/3] i2c: pxa: Add support for the I2C units found in Armada 3700
From: Gregory CLEMENT @ 2016-11-08 15:44 UTC (permalink / raw)
To: Romain Perier
Cc: Wolfram Sang, linux-i2c, devicetree, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Thomas Petazzoni, Nadav Haklai, Omri Itach,
Shadi Ammouri, Yahuda Yitschak, Hanna Hawa, Neta Zur Hershkovits,
Igal Liberman, Marcin Wojtas
In-Reply-To: <20161108151506.1131-2-romain.perier@free-electrons.com>
Hi Romain,
On mar., nov. 08 2016, Romain Perier <romain.perier@free-electrons.com> wrote:
> The Armada 3700 has two I2C controllers that is compliant with the I2C
> Bus Specificiation 2.1, supports multi-master and different bus speed:
> Standard mode (up to 100 KHz), Fast mode (up to 400 KHz),
> High speed mode (up to 3.4 Mhz).
>
> This IP block has a lot of similarity with the PXA, except some register
> offsets and bitfield. This commits adds a basic support for this I2C
> unit.
On the Armada 3720 DB board I manged to run i2cdetect and did some
i2cdump successfully.
Tested-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
During the kernel init I got a:
pxa2xx-i2c d0011000.i2c: failed to get the clk: -517
Maybe an improvement of the driver could be to not output this message
in case of EPROBE_DEFER. Or at least an other message less scary.
Thanks,
Gregory
>
> Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
> ---
> drivers/i2c/busses/Kconfig | 2 +-
> drivers/i2c/busses/i2c-pxa.c | 25 +++++++++++++++++++++++--
> 2 files changed, 24 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
> index d252276..2f56a26 100644
> --- a/drivers/i2c/busses/Kconfig
> +++ b/drivers/i2c/busses/Kconfig
> @@ -763,7 +763,7 @@ config I2C_PUV3
>
> config I2C_PXA
> tristate "Intel PXA2XX I2C adapter"
> - depends on ARCH_PXA || ARCH_MMP || (X86_32 && PCI && OF)
> + depends on ARCH_PXA || ARCH_MMP || ARCH_MVEBU || (X86_32 && PCI && OF)
> help
> If you have devices in the PXA I2C bus, say yes to this option.
> This driver can also be built as a module. If so, the module
> diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
> index e28b825..34ea830 100644
> --- a/drivers/i2c/busses/i2c-pxa.c
> +++ b/drivers/i2c/busses/i2c-pxa.c
> @@ -55,6 +55,7 @@ enum pxa_i2c_types {
> REGS_PXA3XX,
> REGS_CE4100,
> REGS_PXA910,
> + REGS_A3700,
> };
>
> /*
> @@ -91,6 +92,13 @@ static struct pxa_reg_layout pxa_reg_layout[] = {
> .ilcr = 0x28,
> .iwcr = 0x30,
> },
> + [REGS_A3700] = {
> + .ibmr = 0x00,
> + .idbr = 0x04,
> + .icr = 0x08,
> + .isr = 0x0c,
> + .isar = 0x10,
> + },
> };
>
> static const struct platform_device_id i2c_pxa_id_table[] = {
> @@ -98,6 +106,7 @@ static const struct platform_device_id i2c_pxa_id_table[] = {
> { "pxa3xx-pwri2c", REGS_PXA3XX },
> { "ce4100-i2c", REGS_CE4100 },
> { "pxa910-i2c", REGS_PXA910 },
> + { "armada-3700-i2c", REGS_A3700 },
> { },
> };
> MODULE_DEVICE_TABLE(platform, i2c_pxa_id_table);
> @@ -122,7 +131,9 @@ MODULE_DEVICE_TABLE(platform, i2c_pxa_id_table);
> #define ICR_SADIE (1 << 13) /* slave address detected int enable */
> #define ICR_UR (1 << 14) /* unit reset */
> #define ICR_FM (1 << 15) /* fast mode */
> +#define ICR_BUSMODE_FM (1 << 16) /* shifted fast mode for armada-3700 */
> #define ICR_HS (1 << 16) /* High Speed mode */
> +#define ICR_BUSMODE_HS (1 << 17) /* shifted high speed mode for armada-3700 */
> #define ICR_GPIOEN (1 << 19) /* enable GPIO mode for SCL in HS */
>
> #define ISR_RWM (1 << 0) /* read/write mode */
> @@ -193,6 +204,8 @@ struct pxa_i2c {
> unsigned char master_code;
> unsigned long rate;
> bool highmode_enter;
> + unsigned long fm_mask;
> + unsigned long hs_mask;
> };
>
> #define _IBMR(i2c) ((i2c)->reg_ibmr)
> @@ -503,8 +516,8 @@ static void i2c_pxa_reset(struct pxa_i2c *i2c)
> writel(i2c->slave_addr, _ISAR(i2c));
>
> /* set control register values */
> - writel(I2C_ICR_INIT | (i2c->fast_mode ? ICR_FM : 0), _ICR(i2c));
> - writel(readl(_ICR(i2c)) | (i2c->high_mode ? ICR_HS : 0), _ICR(i2c));
> + writel(I2C_ICR_INIT | (i2c->fast_mode ? i2c->fm_mask : 0), _ICR(i2c));
> + writel(readl(_ICR(i2c)) | (i2c->high_mode ? i2c->hs_mask : 0), _ICR(i2c));
>
> #ifdef CONFIG_I2C_PXA_SLAVE
> dev_info(&i2c->adap.dev, "Enabling slave mode\n");
> @@ -1137,6 +1150,7 @@ static const struct of_device_id i2c_pxa_dt_ids[] = {
> { .compatible = "mrvl,pxa-i2c", .data = (void *)REGS_PXA2XX },
> { .compatible = "mrvl,pwri2c", .data = (void *)REGS_PXA3XX },
> { .compatible = "mrvl,mmp-twsi", .data = (void *)REGS_PXA910 },
> + { .compatible = "marvell,armada-3700-i2c", .data = (void *)REGS_A3700 },
> {}
> };
> MODULE_DEVICE_TABLE(of, i2c_pxa_dt_ids);
> @@ -1158,6 +1172,13 @@ static int i2c_pxa_probe_dt(struct platform_device *pdev, struct pxa_i2c *i2c,
> i2c->use_pio = 1;
> if (of_get_property(np, "mrvl,i2c-fast-mode", NULL))
> i2c->fast_mode = 1;
> + if (of_device_is_compatible(np, "marvell,armada-3700-i2c")) {
> + i2c->fm_mask = ICR_BUSMODE_FM;
> + i2c->hs_mask = ICR_BUSMODE_HS;
> + } else {
> + i2c->fm_mask = ICR_FM;
> + i2c->hs_mask = ICR_HS;
> + }
>
> *i2c_types = (enum pxa_i2c_types)(of_id->data);
>
> --
> 2.9.3
>
--
Gregory Clement, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol
From: Russell King - ARM Linux @ 2016-11-08 15:40 UTC (permalink / raw)
To: Sudeep Holla
Cc: Neil Armstrong, devicetree, linux-kernel, Olof Johansson,
linux-amlogic, linux-arm-kernel
In-Reply-To: <28decdc3-6b86-924f-d3c1-9873a8cfce77@arm.com>
On Tue, Nov 08, 2016 at 03:11:07PM +0000, Sudeep Holla wrote:
> On 08/11/16 14:51, Russell King - ARM Linux wrote:
> >On Wed, Nov 02, 2016 at 10:52:03PM -0600, Sudeep Holla wrote:
> >>This is minor rework of the series[1] from Neil Armstrong's to support
> >>legacy SCPI protocol to make DT bindings more generic and move out all
> >>the platform specific bindings out of the generic binding document.
> >
> >Is this what would be in my HBI0282B Juno?
> >
>
> No, it's one on the AmLogic Meson GXBB platform. Juno never supported
> that except that old firmware use it internally. By that I mean some
> version of trusted firmware used legacy SCPI but they are generally
> bundled together in fip, so you should not see any issue with upgrade.
I was wondering whether it'd work with my existing 1st September 2014
version of the trusted firmware. I've pretty much come to the
conclusion that there's no way I can run the later firmware on this
hardware.
> I am currently trying to run Linaro 16.10 release, I don't see any issue
> except network boot from UEFI which is known and reported.
Interesting - maybe the hardware is different then?
> I will go through your logs in detail and try to replicate your issue.
> I assume you have tried replacing the entry contents of the uSD with the
> release. I will start with that now.
I haven't wiped it and copied the entire contents of the zip file over.
I instead backed up the old board.txt and images.txt files, and copied
the HBI0282B directories on top of the others.
This correctly causes all the various components to be updated when the
board boots, updating the MBB BIOS, iofpga, and reprogramming the NOR
flash with the updated images. I even diff'd what was on the uSD card
and what was supplied in the zip file.
That's one state I tested: it also allowed me to edit the board.txt and
similar to wind back to what I have now on the board - which is all the
old versions of the firmware except for the MBB BIOS.
Anyway, I've wiped the uSD, and copied the contents of the 16.10 release
over:
ARM V2M-Juno Boot loader v1.0.0
HBI0262 build 1872
ARM V2M_Juno Firmware v1.4.4
Build Date: Jul 26 2016
Time : 15:18:35
Date : 08:11:2016
Cmd> usb_on
Enabling debug USB...
Cmd> reboot
Powering up system...
Switching on ATXPSU...
PMIC RAM configuration (pms_v103.bin)...
MBtemp : 26 degC
Configuring motherboard (rev B, var B)...
IOFPGA image \MB\HBI0262B\io_b118.bit
IOFPGA config: PASSED
OSC CLK config: PASSED
Configuring SCC registers...
Writing SCC 0x00000054 with 0x0007FFFE
Writing SCC 0x0000005C with 0x00FE001E
Writing SCC 0x00000100 with 0x003F1000
Writing SCC 0x00000104 with 0x0001F300
Writing SCC 0x00000108 with 0x00371000
Writing SCC 0x0000010C with 0x0001B300
Writing SCC 0x00000118 with 0x003F1000
Writing SCC 0x0000011C with 0x0001F100
Writing SCC 0x000000F8 with 0x0BEC0000
Writing SCC 0x000000FC with 0xABE40000
Writing SCC 0x0000000C with 0x000000C2
Writing SCC 0x00000010 with 0x000000C2
Peripheral ID0:0x000000AD
Peripheral ID1:0x000000B0
Peripheral ID2:0x0000000B
Peripheral ID3:0x00000000
Peripheral ID4:0x0000000D
Peripheral ID5:0x000000F0
Peripheral ID6:0x00000005
Peripheral ID7:0x000000B1
Programming NOR Flash
Erasing Flash image Image
........................................
Erasing Flash image juno
.
Erasing Flash image fip
.....
Erasing Flash
......
Writing File fip to Flash Address 0x08000000
.............
Image: fip UPDATED from \SOFTWARE\fip.bin
Erasing Flash image bl1
.
Erasing Flash
.
Writing File bl1 to Flash Address 0x0BEC0000
Image: bl1 UPDATED from \SOFTWARE\bl1.bin
Erasing Flash
.
Writing File norkern to Flash Address 0x08500000
Image: norkern UPDATED from \SOFTWARE\Image
Erasing Flash
.
Writing File board.dtb to Flash Address 0x0A700000
Image: board.dtb UPDATED from \SOFTWARE\juno.dtb
Erasing Flash image ramdisk.img
.
Erasing Flash
.
Writing File ramdisk.img to Flash Address 0x09800000
Image: ramdisk.img UPDATED from \SOFTWARE\ramdisk.img
Erasing Flash image hdlcdclk
.
Erasing Flash
.
Writing File hdlcdclk to Flash Address 0x0A5C0000
Image: hdlcdclk UPDATED from \SOFTWARE\hdlcdclk.dat
Erasing Flash
.
Writing File bl0 to Flash Address 0x0BE40000
Image: bl0 UPDATED from \SOFTWARE\bl0.bin
Erasing Flash
.
Writing File startup.nsh to Flash Address 0x0BF00000
Image: startup.nsh UPDATED from \SOFTWARE\startup.nsh
Erasing Flash
....
Writing File BOOTENV to Flash Address 0x0BFC0000
.
Image: BOOTENV UPDATED from \SOFTWARE\blank.img
Erasing Flash
.
Writing File selftest to Flash Address 0x0A600000
..
Image: selftest UPDATED from \SOFTWARE\selftest
PCIE clock configured...
Testing motherboard interfaces (FPGA build 118)...
SRAM 32MB test: PASSED
LAN9118 test: PASSED
KMI1/2 test: PASSED
MMC test: PASSED
PB/LEDs test: PASSED
FPGA UART test: PASSED
PCIe init test: PASSED
MAC addrs test: PASSED
SMC MAC address 0002-F700-5A7B
Setting HDMI0 mode for SVGA.
Setting HDMI1 mode for SVGA.
SoC SMB clock enabled.
Testing SMB clock...
SMB clock running
Releasing system resets...
UART0 set to SoC UART0
UART1 set to SoC UART1
NOTICE: Booting Trusted Firmware
NOTICE: BL1: v1.2(debug):99e8937
NOTICE: BL1: Built : 12:57:25, Nov 1 2016
INFO: BL1: RAM 0x4037000 - 0x4040000
INFO: Using crypto library 'mbed TLS'
INFO: BL1: Loading BL2
INFO: Loading image id=6 at address 0x4006000
INFO: Skip reserving region [base = 0x4006000, size = 0x37f]
INFO: Image id=6 loaded at address 0x4006000, size = 0x37f
INFO: Loading image id=1 at address 0x4006000
INFO: Image id=1 loaded at address 0x4006000, size = 0x11158
NOTICE: BL1: Booting BL2
INFO: Entry point address = 0x4006000
INFO: SPSR = 0x3c5
NOTICE: BL2: v1.2(debug):99e8937
NOTICE: BL2: Built : 12:57:25, Nov 1 2016
INFO: Using crypto library 'mbed TLS'
INFO: BL2: Loading SCP_BL2
INFO: Loading image id=7 at address 0x4023000
INFO: Skip reserving region [base = 0x4023000, size = 0x5ae]
INFO: Image id=7 loaded at address 0x4023000, size = 0x5ae
INFO: Loading image id=8 at address 0x4023000
INFO: Skip reserving region [base = 0x4023000, size = 0x47a]
INFO: Image id=8 loaded at address 0x4023000, size = 0x47a
INFO: Loading image id=12 at address 0x4023000
INFO: Skip reserving region [base = 0x4023000, size = 0x389]
INFO: Image id=12 loaded at address 0x4023000, size = 0x389
INFO: Loading image id=2 at address 0x4023000
INFO: Skip reserving region [base = 0x4023000, size = 0xf334]
INFO: Image id=2 loaded at address 0x4023000, size = 0xf334
INFO: BL2: Initiating SCP_BL2 transfer to SCP
INFO: BL2: SCP_BL2 transferred to SCP
INFO: Configuring TrustZone Controller
INFO: BL2: Loading BL31
INFO: Loading image id=9 at address 0x4023000
INFO: Skip reserving region [base = 0x4023000, size = 0x47a]
INFO: Image id=9 loaded at address 0x4023000, size = 0x47a
INFO: Loading image id=13 at address 0x4023000
INFO: Skip reserving region [base = 0x4023000, size = 0x389]
INFO: Image id=13 loaded at address 0x4023000, size = 0x389
INFO: Loading image id=3 at address 0x4023000
INFO: Image id=3 loaded at address 0x4023000, size = 0xc020
INFO: BL2: Loading BL32
INFO: Loading image id=10 at address 0xff000000
INFO: Skip reserving region [base = 0xff000000, size = 0x488]
INFO: Image id=10 loaded at address 0xff000000, size = 0x488
INFO: Loading image id=14 at address 0xff000000
INFO: Skip reserving region [base = 0xff000000, size = 0x397]
INFO: Image id=14 loaded at address 0xff000000, size = 0x397
INFO: Loading image id=4 at address 0xff000000
INFO: Image id=4 loaded at address 0xff000000, size = 0x3c0a0
INFO: BL2: Loading BL33
INFO: Loading image id=11 at address 0xe0000000
INFO: Skip reserving region [base = 0xe0000000, size = 0x48b]
INFO: Image id=11 loaded at address 0xe0000000, size = 0x48b
INFO: Loading image id=15 at address 0xe0000000
INFO: Skip reserving region [base = 0xe0000000, size = 0x39a]
INFO: Image id=15 loaded at address 0xe0000000, size = 0x39a
INFO: Loading image id=5 at address 0xe0000000
INFO: Image id=5 loaded at address 0xe0000000, size = 0xf0000
NOTICE: BL1: Booting BL31
INFO: Entry point address = 0x4023000
INFO: SPSR = 0x3cd
NOTICE: BL31: v1.2(debug):99e8937
NOTICE: BL31: Built : 12:57:25, Nov 1 2016
INFO: ARM GICv2 driver initialized
INFO: BL31: Initializing runtime services
INFO: BL31: Initializing BL32
INFO: BL31: Preparing for EL3 exit to normal world
INFO: Entry point address = 0xe0000000
INFO: SPSR = 0x3c9
UEFI firmware (version f51ab72 built at 12:57:40 on Nov 1 2016)
add-symbol-file /home/buildslave/workspace/armlt-platforms-release/workspace-pinned-uefi/uefi/edk2/Build/ArmJuno/DEBUG_GCC49/AARCH64/ArmPlatformPkg/PrePi/PeiUniCore/DEBUG/ArmPlatformPrePiUniCore.dll 0xE0000800
add-symbol-file /home/buildslave/workspace/armlt-platforms-release/workspace-pinned-uefi/uefi/edk2/Build/ArmJuno/DEBUG_GCC49/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll 0xFE03C000
Loading DxeCore at 0x00FE03B000 EntryPoint=0x00FE03C000
add-symbol-file /home/buildslave/workspace/armlt-platforms-release/workspace-pinned-uefi/uefi/edk2/Build/ArmJuno/DEBUG_GCC49/AARCH64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll 0xFE03C000
HOBLIST address in DXE = 0xFDDFE018
Memory Allocation 0x00000004 0xFEFEA000 - 0xFEFEAFFF
Memory Allocation 0x00000004 0xFEFE9000 - 0xFEFE9FFF
Memory Allocation 0x00000004 0xFEFE8000 - 0xFEFE8FFF
Memory Allocation 0x00000004 0xFEFE7000 - 0xFEFE7FFF
Memory Allocation 0x00000004 0xFEFE6000 - 0xFEFE6FFF
Memory Allocation 0x00000004 0xFEFE5000 - 0xFEFE5FFF
Memory Allocation 0x00000004 0xFEFE4000 - 0xFEFE4FFF
Memory Allocation 0x00000004 0xFEFE3000 - 0xFEFE3FFF
Memory Allocation 0x00000004 0xFEFEB000 - 0xFEFFFFFF
Memory Allocation 0x00000004 0xFEFD3000 - 0xFEFE2FFF
Memory Allocation 0x00000004 0xFE827000 - 0xFEFD2FFF
Memory Allocation 0x00000004 0xFE07B000 - 0xFE826FFF
Memory Allocation 0x00000004 0xFE03B000 - 0xFE07AFFF
Memory Allocation 0x00000003 0xFE03B000 - 0xFE07AFFF
FV Hob 0xE0000000 - 0xE00EFFFF
FV Hob 0xFE07B000 - 0xFE8253BF
FV2 Hob 0xFE07B000 - 0xFE8253BF
which looks more hopeful... except it stops there.
As it contains a zero sized Image and .dtb files, I tried copying my
Image and .dtb over, and also copied my original config.txt (only
change is AUTORUN: FALSE). It still doesn't appear to boot beyond
this point.
--
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 3/3] dt-bindings: i2c: pxa: Update the documentation for the Armada 3700
From: Romain Perier @ 2016-11-08 15:15 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c
Cc: devicetree, Rob Herring, Ian Campbell, Pawel Moll, Mark Rutland,
Kumar Gala, Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
Gregory Clement, Thomas Petazzoni, Nadav Haklai, Omri Itach,
Shadi Ammouri, Yahuda Yitschak, Hanna Hawa, Neta Zur Hershkovits,
Igal Liberman, Marcin Wojtas
In-Reply-To: <20161108151506.1131-1-romain.perier@free-electrons.com>
This commit documents the compatible string to have the compatibility for
the I2C unit found in the Armada 3700.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
index 12b78ac..b1b995c 100644
--- a/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
+++ b/Documentation/devicetree/bindings/i2c/i2c-pxa.txt
@@ -7,6 +7,7 @@ Required properties :
compatible processor, e.g. pxa168, pxa910, mmp2, mmp3.
For the pxa2xx/pxa3xx, an additional node "mrvl,pxa-i2c" is required
as shown in the example below.
+ For the Armada 3700, the compatible should be "marvell,armada-3700".
Recommended properties :
--
2.9.3
^ permalink raw reply related
* [PATCH 2/3] arm64: dts: marvell: Add I2C definitions for the Armada 3700
From: Romain Perier @ 2016-11-08 15:15 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c
Cc: devicetree, Rob Herring, Ian Campbell, Pawel Moll, Mark Rutland,
Kumar Gala, Jason Cooper, Andrew Lunn, Sebastian Hesselbarth,
Gregory Clement, Thomas Petazzoni, Nadav Haklai, Omri Itach,
Shadi Ammouri, Yahuda Yitschak, Hanna Hawa, Neta Zur Hershkovits,
Igal Liberman, Marcin Wojtas
In-Reply-To: <20161108151506.1131-1-romain.perier@free-electrons.com>
The Armada 3700 has two i2c bus interface units, this commit adds the
definitions of the corresponding device nodes. It also enables the node
on the development board for this SoC.
Signed-off-by: Romain Perier <romain.perier@free-electrons.com>
---
arch/arm64/boot/dts/marvell/armada-3720-db.dts | 4 ++++
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 18 ++++++++++++++++++
2 files changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-3720-db.dts b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
index 1372e9a6..16d84af 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
@@ -62,6 +62,10 @@
};
};
+&i2c0 {
+ status = "okay";
+};
+
/* CON3 */
&sata {
status = "okay";
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index c476253..bf2d73d 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -98,6 +98,24 @@
/* 32M internal register @ 0xd000_0000 */
ranges = <0x0 0x0 0xd0000000 0x2000000>;
+ i2c0: i2c@11000 {
+ compatible = "marvell,armada-3700-i2c";
+ reg = <0x11000 0x24>;
+ clocks = <&nb_perih_clk 10>;
+ interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>;
+ mrvl,i2c-fast-mode;
+ status = "disabled";
+ };
+
+ i2c1: i2c@11080 {
+ compatible = "marvell,armada-3700-i2c";
+ reg = <0x11080 0x24>;
+ clocks = <&nb_perih_clk 9>;
+ interrupts = <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>;
+ mrvl,i2c-fast-mode;
+ status = "disabled";
+ };
+
uart0: serial@12000 {
compatible = "marvell,armada-3700-uart";
reg = <0x12000 0x400>;
--
2.9.3
^ permalink raw reply related
* [PATCH 1/3] i2c: pxa: Add support for the I2C units found in Armada 3700
From: Romain Perier @ 2016-11-08 15:15 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c-u79uwXL29TY76Z2rM5mHXA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Thomas Petazzoni,
Nadav Haklai, Omri Itach, Shadi Ammouri, Yahuda Yitschak,
Hanna Hawa, Neta Zur Hershkovits, Igal Liberman, Marcin Wojtas
In-Reply-To: <20161108151506.1131-1-romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
The Armada 3700 has two I2C controllers that is compliant with the I2C
Bus Specificiation 2.1, supports multi-master and different bus speed:
Standard mode (up to 100 KHz), Fast mode (up to 400 KHz),
High speed mode (up to 3.4 Mhz).
This IP block has a lot of similarity with the PXA, except some register
offsets and bitfield. This commits adds a basic support for this I2C
unit.
Signed-off-by: Romain Perier <romain.perier-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
---
drivers/i2c/busses/Kconfig | 2 +-
drivers/i2c/busses/i2c-pxa.c | 25 +++++++++++++++++++++++--
2 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index d252276..2f56a26 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -763,7 +763,7 @@ config I2C_PUV3
config I2C_PXA
tristate "Intel PXA2XX I2C adapter"
- depends on ARCH_PXA || ARCH_MMP || (X86_32 && PCI && OF)
+ depends on ARCH_PXA || ARCH_MMP || ARCH_MVEBU || (X86_32 && PCI && OF)
help
If you have devices in the PXA I2C bus, say yes to this option.
This driver can also be built as a module. If so, the module
diff --git a/drivers/i2c/busses/i2c-pxa.c b/drivers/i2c/busses/i2c-pxa.c
index e28b825..34ea830 100644
--- a/drivers/i2c/busses/i2c-pxa.c
+++ b/drivers/i2c/busses/i2c-pxa.c
@@ -55,6 +55,7 @@ enum pxa_i2c_types {
REGS_PXA3XX,
REGS_CE4100,
REGS_PXA910,
+ REGS_A3700,
};
/*
@@ -91,6 +92,13 @@ static struct pxa_reg_layout pxa_reg_layout[] = {
.ilcr = 0x28,
.iwcr = 0x30,
},
+ [REGS_A3700] = {
+ .ibmr = 0x00,
+ .idbr = 0x04,
+ .icr = 0x08,
+ .isr = 0x0c,
+ .isar = 0x10,
+ },
};
static const struct platform_device_id i2c_pxa_id_table[] = {
@@ -98,6 +106,7 @@ static const struct platform_device_id i2c_pxa_id_table[] = {
{ "pxa3xx-pwri2c", REGS_PXA3XX },
{ "ce4100-i2c", REGS_CE4100 },
{ "pxa910-i2c", REGS_PXA910 },
+ { "armada-3700-i2c", REGS_A3700 },
{ },
};
MODULE_DEVICE_TABLE(platform, i2c_pxa_id_table);
@@ -122,7 +131,9 @@ MODULE_DEVICE_TABLE(platform, i2c_pxa_id_table);
#define ICR_SADIE (1 << 13) /* slave address detected int enable */
#define ICR_UR (1 << 14) /* unit reset */
#define ICR_FM (1 << 15) /* fast mode */
+#define ICR_BUSMODE_FM (1 << 16) /* shifted fast mode for armada-3700 */
#define ICR_HS (1 << 16) /* High Speed mode */
+#define ICR_BUSMODE_HS (1 << 17) /* shifted high speed mode for armada-3700 */
#define ICR_GPIOEN (1 << 19) /* enable GPIO mode for SCL in HS */
#define ISR_RWM (1 << 0) /* read/write mode */
@@ -193,6 +204,8 @@ struct pxa_i2c {
unsigned char master_code;
unsigned long rate;
bool highmode_enter;
+ unsigned long fm_mask;
+ unsigned long hs_mask;
};
#define _IBMR(i2c) ((i2c)->reg_ibmr)
@@ -503,8 +516,8 @@ static void i2c_pxa_reset(struct pxa_i2c *i2c)
writel(i2c->slave_addr, _ISAR(i2c));
/* set control register values */
- writel(I2C_ICR_INIT | (i2c->fast_mode ? ICR_FM : 0), _ICR(i2c));
- writel(readl(_ICR(i2c)) | (i2c->high_mode ? ICR_HS : 0), _ICR(i2c));
+ writel(I2C_ICR_INIT | (i2c->fast_mode ? i2c->fm_mask : 0), _ICR(i2c));
+ writel(readl(_ICR(i2c)) | (i2c->high_mode ? i2c->hs_mask : 0), _ICR(i2c));
#ifdef CONFIG_I2C_PXA_SLAVE
dev_info(&i2c->adap.dev, "Enabling slave mode\n");
@@ -1137,6 +1150,7 @@ static const struct of_device_id i2c_pxa_dt_ids[] = {
{ .compatible = "mrvl,pxa-i2c", .data = (void *)REGS_PXA2XX },
{ .compatible = "mrvl,pwri2c", .data = (void *)REGS_PXA3XX },
{ .compatible = "mrvl,mmp-twsi", .data = (void *)REGS_PXA910 },
+ { .compatible = "marvell,armada-3700-i2c", .data = (void *)REGS_A3700 },
{}
};
MODULE_DEVICE_TABLE(of, i2c_pxa_dt_ids);
@@ -1158,6 +1172,13 @@ static int i2c_pxa_probe_dt(struct platform_device *pdev, struct pxa_i2c *i2c,
i2c->use_pio = 1;
if (of_get_property(np, "mrvl,i2c-fast-mode", NULL))
i2c->fast_mode = 1;
+ if (of_device_is_compatible(np, "marvell,armada-3700-i2c")) {
+ i2c->fm_mask = ICR_BUSMODE_FM;
+ i2c->hs_mask = ICR_BUSMODE_HS;
+ } else {
+ i2c->fm_mask = ICR_FM;
+ i2c->hs_mask = ICR_HS;
+ }
*i2c_types = (enum pxa_i2c_types)(of_id->data);
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH 0/3] Add basic support for the I2C units of the Armada 3700
From: Romain Perier @ 2016-11-08 15:15 UTC (permalink / raw)
To: Wolfram Sang, linux-i2c-u79uwXL29TY76Z2rM5mHXA
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala, Jason Cooper, Andrew Lunn,
Sebastian Hesselbarth, Gregory Clement, Thomas Petazzoni,
Nadav Haklai, Omri Itach, Shadi Ammouri, Yahuda Yitschak,
Hanna Hawa, Neta Zur Hershkovits, Igal Liberman, Marcin Wojtas
This series add basic support for the I2C bus interface units present
in the Armada 3700 to the pxa-i2c driver. It also add the definitions of
the device nodes to the devicetree at the SoC level and for its official
development board: the Armada 3720 DB.
Romain Perier (3):
i2c: pxa: Add support for the I2C units found in Armada 3700
arm64: dts: marvell: Add I2C definitions for the Armada 3700
dt-bindings: i2c: pxa: Update the documentation for the Armada 3700
Documentation/devicetree/bindings/i2c/i2c-pxa.txt | 1 +
arch/arm64/boot/dts/marvell/armada-3720-db.dts | 4 ++++
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 18 ++++++++++++++++
drivers/i2c/busses/Kconfig | 2 +-
drivers/i2c/busses/i2c-pxa.c | 25 +++++++++++++++++++++--
5 files changed, 47 insertions(+), 3 deletions(-)
--
2.9.3
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol
From: Sudeep Holla @ 2016-11-08 15:11 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Sudeep Holla, Neil Armstrong, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Olof Johansson,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161108145118.GR1041-l+eeeJia6m9URfEZ8mYm6t73F7V6hmMc@public.gmane.org>
On 08/11/16 14:51, Russell King - ARM Linux wrote:
> On Wed, Nov 02, 2016 at 10:52:03PM -0600, Sudeep Holla wrote:
>> This is minor rework of the series[1] from Neil Armstrong's to support
>> legacy SCPI protocol to make DT bindings more generic and move out all
>> the platform specific bindings out of the generic binding document.
>
> Is this what would be in my HBI0282B Juno?
>
No, it's one on the AmLogic Meson GXBB platform. Juno never supported
that except that old firmware use it internally. By that I mean some
version of trusted firmware used legacy SCPI but they are generally
bundled together in fip, so you should not see any issue with upgrade.
> (Note: I only have the original firmware on the board, as the Linaro
> firmware drops are completely broken for it.)
>
I am currently trying to run Linaro 16.10 release, I don't see any issue
except network boot from UEFI which is known and reported.
I will go through your logs in detail and try to replicate your issue.
I assume you have tried replacing the entry contents of the uSD with the
release. I will start with that now.
--
Regards,
Sudeep
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] gpio: xilinx: Add clock support
From: Sören Brinkmann @ 2016-11-08 14:52 UTC (permalink / raw)
To: Shubhrajyoti Datta; +Cc: linux-gpio, devicetree, michal.simek
In-Reply-To: <1478581990-28276-2-git-send-email-shubhrajyoti.datta@xilinx.com>
On Tue, 2016-11-08 at 10:43:10 +0530, Shubhrajyoti Datta wrote:
> Add basic clock support for xilinx gpio.
>
> Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@xilinx.com>
> ---
> drivers/gpio/gpio-xilinx.c | 22 ++++++++++++++++++++++
> 1 files changed, 22 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/gpio/gpio-xilinx.c b/drivers/gpio/gpio-xilinx.c
> index 14b2a62..923cab8 100644
> --- a/drivers/gpio/gpio-xilinx.c
> +++ b/drivers/gpio/gpio-xilinx.c
> @@ -13,6 +13,7 @@
> */
>
> #include <linux/bitops.h>
> +#include <linux/clk.h>
> #include <linux/init.h>
> #include <linux/errno.h>
> #include <linux/module.h>
> @@ -45,6 +46,7 @@
> * @gpio_state: GPIO state shadow register
> * @gpio_dir: GPIO direction shadow register
> * @gpio_lock: Lock used for synchronization
> + * @clk: Clock resource for this controller
> */
> struct xgpio_instance {
> struct of_mm_gpio_chip mmchip;
> @@ -52,6 +54,7 @@ struct xgpio_instance {
> u32 gpio_state[2];
> u32 gpio_dir[2];
> spinlock_t gpio_lock[2];
> + struct clk *clk;
> };
>
> static inline int xgpio_index(struct xgpio_instance *chip, int gpio)
> @@ -282,6 +285,7 @@ static int xgpio_remove(struct platform_device *pdev)
> struct xgpio_instance *chip = platform_get_drvdata(pdev);
>
> of_mm_gpiochip_remove(&chip->mmchip);
> + clk_disable_unprepare(chip->clk);
>
> return 0;
> }
> @@ -307,6 +311,23 @@ static int xgpio_probe(struct platform_device *pdev)
>
> platform_set_drvdata(pdev, chip);
>
> + /* Retrieve GPIO clock */
> + chip->clk = devm_clk_get(&pdev->dev, NULL);
> + if (IS_ERR(chip->clk)) {
> + if (PTR_ERR(chip->clk) == -ENOENT) {
> + dev_info(&pdev->dev, "No clocks found for clk\n");
> + chip->clk = NULL;
> + } else {
> + dev_err(&pdev->dev, "axi clock error\n");
> + return PTR_ERR(chip->clk);
> + }
> + }
In the bindings you document 'clocks' as required, but it's handled as
optional here. Things should be consistent and given that the existing
binding doesn't require clocks, we're probably stuck with having the
clock optional.
Sören
^ permalink raw reply
* Re: [PATCH 0/8] firmware: arm_scpi: add support for legacy SCPI protocol
From: Russell King - ARM Linux @ 2016-11-08 14:51 UTC (permalink / raw)
To: Sudeep Holla
Cc: Neil Armstrong, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, Olof Johansson,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1478148731-11712-1-git-send-email-sudeep.holla-5wv7dgnIgG8@public.gmane.org>
On Wed, Nov 02, 2016 at 10:52:03PM -0600, Sudeep Holla wrote:
> This is minor rework of the series[1] from Neil Armstrong's to support
> legacy SCPI protocol to make DT bindings more generic and move out all
> the platform specific bindings out of the generic binding document.
Is this what would be in my HBI0282B Juno?
(Note: I only have the original firmware on the board, as the Linaro
firmware drops are completely broken for it.)
--
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.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 0/5] ARM: da850: new drivers for better LCDC support
From: Sekhar Nori @ 2016-11-08 14:50 UTC (permalink / raw)
To: Bartosz Golaszewski, Kevin Hilman, Michael Turquette, Rob Herring,
Frank Rowand, Mark Rutland, Peter Ujfalusi, Russell King
Cc: LKML, arm-soc, linux-drm, linux-devicetree, Jyri Sarha,
Tomi Valkeinen, David Airlie, Laurent Pinchart, Arnd Bergmann,
Olof Johansson
In-Reply-To: <1477925138-23457-1-git-send-email-bgolaszewski@baylibre.com>
+ Arnd, Olof
On Monday 31 October 2016 08:15 PM, Bartosz Golaszewski wrote:
> This series adds two new drivers in order to better support the LCDC
> rev1 present on the da850 boards.
>
> The first patch adds a new memory driver which allows to write to the
> DDR2/mDDR memory controller present on the da8xx SoCs.
>
> The second patch adds a new bus driver which allows to interact with
> the MSTPRI registers of the SYSCFG0 module
I think patches 1/5 and 2/5 are ready to be merged. If there are no
objections I would like to send a pull request for them to be merged
through ARM-SoC tree for v4.10 kernel.
Thanks,
Sekhar
>
> As is mentioned in the comments: we don't want to commit to supporting
> stable interfaces (DT bindings or sysfs attributes) so we hardcode the
> settings required by some boards (for now only da850-lcdk) with the
> hope that linux gets an appropriate framework for performance knobs
> in the future.
>
> Potential extensions of these drivers should be straightforward in the
> future.
>
> Subsequent patches add DT nodes for the new drivers: disabled nodes
> in da850.dtsi and enabled in da850-lcdk.dts.
>
> The last patch adds a workaround for current lack of support for drm
> bridges in tilcdc.
>
> Tested on a da850-lcdk with a display connected over VGA and two
> additional patches for tilcdc (sent to linux-drm): ran simple modetest
> for supported resolutions, used X.org and fluxbox as graphical
> environment, played video with mplayer.
>
> v1 -> v2:
> - used regular readl()/writel() instead of __raw_** versions
> - used resource_size() instead of calculating the size by hand
> - used ioremap instead of syscon in patch [2/5]
> - added the DT nodes in patches [3/5]-[5/5]
>
> Bartosz Golaszewski (5):
> ARM: memory: da8xx-ddrctl: new driver
> ARM: bus: da8xx-mstpri: new driver
> ARM: dts: da850: add the mstpri and ddrctl nodes
> ARM: dts: da850-lcdk: enable mstpri and ddrctl nodes
> ARM: dts: da850-lcdk: add tilcdc panel node
>
> .../devicetree/bindings/bus/ti,da850-mstpri.txt | 20 ++
> .../memory-controllers/ti-da8xx-ddrctl.txt | 20 ++
> arch/arm/boot/dts/da850-lcdk.dts | 71 ++++++
> arch/arm/boot/dts/da850.dtsi | 11 +
> drivers/bus/Kconfig | 9 +
> drivers/bus/Makefile | 2 +
> drivers/bus/da8xx-mstpri.c | 269 +++++++++++++++++++++
> drivers/memory/Kconfig | 8 +
> drivers/memory/Makefile | 1 +
> drivers/memory/da8xx-ddrctl.c | 175 ++++++++++++++
> 10 files changed, 586 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/bus/ti,da850-mstpri.txt
> create mode 100644 Documentation/devicetree/bindings/memory-controllers/ti-da8xx-ddrctl.txt
> create mode 100644 drivers/bus/da8xx-mstpri.c
> create mode 100644 drivers/memory/da8xx-ddrctl.c
>
^ permalink raw reply
* Re: [PATCH 1/2] gpio: xilinx: dt-binding: Add clock node
From: Sören Brinkmann @ 2016-11-08 14:48 UTC (permalink / raw)
To: Shubhrajyoti Datta
Cc: linux-gpio-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
michal.simek-gjFFaj9aHVfQT0dZR+AlfA
In-Reply-To: <1478581990-28276-1-git-send-email-shubhrajyoti.datta-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
On Tue, 2016-11-08 at 10:43:09 +0530, Shubhrajyoti Datta wrote:
> Add the clock node to the dt binding.
>
> Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta-gjFFaj9aHVfQT0dZR+AlfA@public.gmane.org>
> ---
> .../devicetree/bindings/gpio/gpio-xilinx.txt | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-xilinx.txt b/Documentation/devicetree/bindings/gpio/gpio-xilinx.txt
> index 63bf4be..0821b9d 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio-xilinx.txt
> +++ b/Documentation/devicetree/bindings/gpio/gpio-xilinx.txt
> @@ -11,6 +11,7 @@ Required properties:
> - #gpio-cells : Should be two. The first cell is the pin number and the
> second cell is used to specify optional parameters (currently unused).
> - gpio-controller : Marks the device node as a GPIO controller.
> +- clocks: Input clock specifier. Refer to common clock bindings.
>
> Optional properties:
> - interrupts : Interrupt mapping for GPIO IRQ.
> @@ -25,12 +26,14 @@ Optional properties:
> - xlnx,dout-default-2 : as above but the second channel
> - xlnx,gpio2-width : as above but for the second channel
> - xlnx,tri-default-2 : as above but for the second channel
> +- clock-names: Input clock name
Clock names are driver specific and must be documented here.
>
>
> Example:
> gpio: gpio@40000000 {
> #gpio-cells = <2>;
> compatible = "xlnx,xps-gpio-1.00.a";
> + clocks = <&clkc 15>;
Where are the clock-names?
Sören
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH v2] iio: document bindings for mounting matrices
From: Linus Walleij @ 2016-11-08 14:45 UTC (permalink / raw)
To: Jonathan Cameron, linux-iio-u79uwXL29TY76Z2rM5mHXA
Cc: Linus Walleij, Gregor Boirie, Sebastian Reichel, Samu Onkalo,
devicetree-u79uwXL29TY76Z2rM5mHXA
The mounting matrix for sensors was introduced in
commit dfc57732ad38 ("iio:core: mounting matrix support")
However the device tree bindings are very terse and since this is
a widely applicable property, we need a proper binding for it
that the other bindings can reference. This will also be useful
for other operating systems and sensor engineering at large.
I think all 3D sensors should support it, the current situation
is probably that the mounting information is confined in magic
userspace components rather than using the mounting matrix, which
is not good for portability and reuse.
Cc: Gregor Boirie <gregor.boirie-ITF29qwbsa/QT0dZR+AlfA@public.gmane.org>
Cc: Sebastian Reichel <sre-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Samu Onkalo <samu.onkalo-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Signed-off-by: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
---
ChangeLog v1->v2:
- Repeat linear algebra and actually get the rotation matrix right.
- Reference the Wikipedia article on the subject.
- Fix up text.
---
.../devicetree/bindings/iio/mount-matrix.txt | 108 +++++++++++++++++++++
1 file changed, 108 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/mount-matrix.txt
diff --git a/Documentation/devicetree/bindings/iio/mount-matrix.txt b/Documentation/devicetree/bindings/iio/mount-matrix.txt
new file mode 100644
index 000000000000..a3714727f739
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/mount-matrix.txt
@@ -0,0 +1,108 @@
+Mounting matrix
+
+The mounting matrix is a device tree property used to orient any IIO device
+that produce three-dimensional data in relation to the world where it is
+deployed.
+
+The purpose of the mounting matrix is to translate the sensor frame of
+reference into the device frame of reference using a translation matrix as
+defined in linear algebra.
+
+The typical usecase is that where a component has an internal representation
+of the (x,y,z) triplets, such as different registers to read these coordinates,
+and thus implying that the component should be mounted in a certain orientation
+relative to some specific device frame of reference.
+
+For example a device with some kind of screen, where the user is supposed to
+interact with the environment using an accelerometer, gyroscope or magnetometer
+mounted on the same chassis as this screen, will likely take the screen as
+reference to (x,y,z) orientation, with (x,y) corresponding to these axes on the
+screen and (z) being depth, the axis perpendicular to the screen.
+
+For a screen you probably want (x) coordinates to go from negative on the left
+to positive on the right and (z) depth to be negative under the screen and
+positive in front of it, toward the face of the user.
+
+A sensor can be mounted in any angle along the axes relative to the frame of
+reference. This means that the sensor may be flipped upside-down, left-right,
+or tilted at any angle relative to the frame of reference.
+
+Another frame of reference is how the device with its sensor relates to the
+external world, the environment where the device is deployed. Usually the data
+from the sensor is used to figure out how the device is oriented with respect
+to this world. When using the mounting matrix, the sensor and device orientation
+becomes identical and we can focus on the data as it relates to the surrounding
+world.
+
+Device-to-world examples for some three-dimensional sensor types:
+
+- Accelerometers have their world frame of reference toward the center of
+ gravity, usually to the core of the planet. A reading of the (x,y,z) values
+ from the sensor will give a projection of the gravity vector through the
+ device relative to the center of the planet, i.e. relative to its surface at
+ this point. Up and down in the world relative to the device frame of
+ reference can thus be determined. and users would likely expect a value of
+ 9.81 m/s^2 upwards along the (z) axis, i.e. out of the screen when the device
+ is held with its screen flat on the planets surface and 0 on the other axes,
+ as the gravity vector is projected 1:1 onto the sensors (z)-axis.
+
+- Magnetometers (compasses) have their world frame of reference relative to the
+ geomagnetic field. The system orientation vis-a-vis the world is defined with
+ respect to the local earth geomagnetic reference frame where (y) is in the
+ ground plane and positive towards magnetic North, (x) is in the ground plane,
+ perpendicular to the North axis and positive towards the East and (z) is
+ perpendicular to the ground plane and positive upwards.
+
+- Gyroscopes detects the movement relative the device itself. The angular
+ velocity is defined as orthogonal to the plane of rotation, so if you put the
+ device on a flat surface and spin it around the z axis (such as rotating a
+ device with a screen lying flat on a table), you should get a negative value
+ along the (z) axis if rotated clockwise, and a positive value if rotated
+ counter-clockwise according to the right-hand rule.
+
+So unless the sensor is ideally mounted, we need a means to indicate the
+relative orientation of any given sensor of this type with respect to the
+frame of reference.
+
+To achieve this, use the device tree property "mount-matrix" for the sensor.
+This supplies a 3x3 rotation matrix in the strict linear algebraic sense,
+to orient the senor axes relative to a desired point of reference. This means
+the resulting values from the sensor, after scaling to proper units, should be
+multiplied by this matrix to give the proper vectors values in three-dimensional
+space, relative to the device or world point of reference.
+
+For more information, consult:
+https://en.wikipedia.org/wiki/Rotation_matrix
+
+The mounting matrix has the layout:
+
+ (x0, y0, z0)
+ (x1, y1, z1)
+ (x2, y2, z3)
+
+And it is represented as an array of strings containing the real values for
+producing the transformation matrix. The real values use a decimal point and
+a minus (-) to indicate a negative value.
+
+Examples:
+
+Identity matrix (nothing happens to the coordinates, which means the device was
+mechanically mounted in an ideal way and we need no transformation):
+
+mount-matrix = "1", "0", "0",
+ "0", "1", "0",
+ "0", "0", "1";
+
+The sensor is mounted 30 degrees (Pi/6 radians) tilted along the X axis, so we
+compensate by performing a -30 degrees rotation around the X axis:
+
+mount-matrix = "1", "0", "0",
+ "0", "0.866", "0.5",
+ "0", "-0.5", "0.866";
+
+The sensor is flipped 180 degrees (Pi radians) around the Z axis, i.e. mounted
+upside-down:
+
+mount-matrix = "0.998", "0.054", "0",
+ "-0.054", "0.998", "0",
+ "0", "0", "1";
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH 1/4] pinctrl: Introduce generic #pinctrl-cells and pinctrl_parse_index_with_args
From: Tony Lindgren @ 2016-11-08 14:44 UTC (permalink / raw)
To: Linus Walleij
Cc: Jon Hunter, Mark Rutland, Rob Herring, Grygorii Strashko,
Nishanth Menon,
linux-gpio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Linux-OMAP
In-Reply-To: <CACRpkdbdfM8qtMSE1O-VEsnOHGbVuMDhOFtELvqoYuE1JJ=GRg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
* Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> [161108 03:32]:
> On Mon, Nov 7, 2016 at 4:26 PM, Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org> wrote:
> > * Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> [161104 14:50]:
>
> >> +struct of_phandle_args;
> >> +
> >> #ifdef CONFIG_OF
> >>
> >> Let's see if it works!
> >
> > OK so do we know now? It seems there was one more email
> > about it but it may have been without it.
>
> I haven't seen anything, I think it JustWorks(TM).
OK good to to hear :)
Thanks,
Tony
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 2/2] pinctrl: tegra: Add driver to configure voltage and power of io pads
From: Thierry Reding @ 2016-11-08 14:42 UTC (permalink / raw)
To: Laxman Dewangan
Cc: Linus Walleij, Stephen Warren, Rob Herring, Mark Rutland,
Jon Hunter, Masahiro Yamada, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-tegra@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <5821D49E.2070308@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 4950 bytes --]
On Tue, Nov 08, 2016 at 07:05:26PM +0530, Laxman Dewangan wrote:
>
> On Tuesday 08 November 2016 06:59 PM, Linus Walleij wrote:
> > On Tue, Nov 8, 2016 at 11:20 AM, Laxman Dewangan <ldewangan@nvidia.com> wrote:
> > > On Tuesday 08 November 2016 03:45 PM, Linus Walleij wrote:
> > > > If you can *actually* change the volatage, it needs to be modeled
> > > > as a (fixed voltage?) regulator, not as a custom property for the pin
> > > > control attributes. I guess you definiately need the regulator framework
> > > > to accumulate and infer the different consumer requirements anyway
> > > > in that case.
> > > The PMIC voltage output is changed via regulator calls.
> > > Here, we need to have two configruations for given voltage level of
> > > interface:
> > > * One at IO voltage from PMIC via regulator call to change votlage of IO
> > > rail.
> > > * Second, configure the IO pad register to tell the IO voltage level so that
> > > it can configured internally for that level.
> > I understand! (I think.)
>
> Thanks,
>
> >
> > But then the two things (A) changing the regulator voltage and (B) changing
> > the pin setting need to happen at the same time do they
> > not?
> >
> > Now you're just hardcoding something into these device tree properties
> > and hoping that the regulators will somehow be set up in accordance to
> > what you set up for the pads in the device tree, correct?
>
> There is two types of configuration in given platform, the IO voltage does
> not get change (fixed in given platform) and in some of cases, get change
> dynamically like SDIO3.0 where the voltage switches to 3.3V and 1.8V.
>
> Yes, it can be integrated with the regulator handle and then it can call the
> required configurations through notifier and regulator_get_voltage().
> But I think it is too much complex for the static configurations. This
> mandate also to populate the regulator handle and all power tree.
It looks as if regulator notifiers should be able to support whatever
use-cases we may have (I suspect that we really only need pre- and post-
voltage-change notifications.
> The simple way for static configuration (case where voltage does not get
> change), just take the power tree IO voltage from DT and configure the IO
> pad control register.
For static configurations where we have a regulator along with a pinmux
setting for the I/O voltage we could potentially run into issues where
both settings don't match. How would we handle that?
> For dynamic case, there is some sequence need to be followed based on
> voltage direction change (towards lower or towards higher) for the voltage
> change and the IO pad voltage configuration and it is simple to do it from
> client driver.
Are patches available for this? It'd be useful to know how this will end
up being used in order to come up with the best solution.
In general I think it's good to send a complete series of patches, even
if it's long and spans multiple subsystems. As it is it's difficult for
anyone else (myself included) to understand where this is headed, which
makes it more complicated than necessary to get at the final solution.
> > To me it seems like the pins/pads should all have an <&phandle> to
> > the regulator controlling its voltage output, in the device tree.
> >
> > In the Linux kernel, the driver has to regulator_[bulk_]get() this for
> > each pin, check the voltage with regulator_get_voltage() and set up
> > this according to the supplied voltage.
> >
> > The driver then ideally should subscribe to regulator voltage notifier
> > events to change the setting if the voltage changes. I guess. But
> > atleast the first step seems inevitable: get the voltage from a regulator.
> >
> > Else there is no dependency between the regulator and its consumer.
> >
> > So what your pins need is a regulator phandle, not a magic value to
> > be poked into a register, hoping things will match up.
> >
> > I understand that this is a simple quick-and-dirty solution but it is
> > not the right solution.
>
>
> Yaah, the static power tree configuration is much simple in this approach
> without having regulator drivers and support.
>
> Integrating with regulator driver can be done here also.
>
> I like to have both approach, through pinmux DT and also from regulator. So
> based on the platform, if regulator supported then populate required
> properties in DT for regulator else go on standard pinmux DT way (for
> non-regulator cases).
Again, it would be best to see this in actual use. Right now it's not
clear that we'll even have both cases. Implementing both approaches will
mean potentially unused code.
On another note: in my experience you seldom need both cases, since the
dynamic configuration is the hard one, and the static configuration will
usually be a special case of the dynamic configuration.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH v5 1/7] drm: sunxi: Add a basic DRM driver for Allwinner DE2
From: Jean-Francois Moine @ 2016-11-08 14:37 UTC (permalink / raw)
To: Maxime Ripard
Cc: Dave Airlie, Liam Girdwood, Mark Brown, Rob Herring,
alsa-devel-K7yf7f+aM1XWsZ/bQMPhNw,
devicetree-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20161107223741.gjxj4tqwuxud2iqc@lukather>
On Mon, 7 Nov 2016 23:37:41 +0100
Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> Hi,
>
> On Fri, Oct 28, 2016 at 07:34:20PM +0200, Jean-Francois Moine wrote:
> > On Fri, 28 Oct 2016 00:03:16 +0200
> > Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
[snip]
> > > > > We've been calling them bus and mod.
> > > >
> > > > I can understand "bus" (which is better than "apb"), but why "mod"?
> > >
> > > Allwinner has been calling the clocks that are supposed to generate
> > > the external signals (depending on where you were looking) module or
> > > mod clocks (which is also why we have mod in the clock
> > > compatibles). The module 1 clocks being used for the audio and the
> > > module 0 for the rest (SPI, MMC, NAND, display, etc.)
> >
> > I did not find any 'module' in the H3 documentation.
> > So, is it really a good name?
>
> It's true that they use it less nowadays, but they still do,
> ie. https://github.com/allwinner-zh/linux-3.4-sunxi/blob/master/drivers/clk/sunxi/clk-sun8iw7.c#L513
There is a 'mod' suffix, but it is used for the bus gates only, not for
the main clocks.
> And we have to remain consistent anyway.
I don't see any consistency in the H3 DT:
- the bus gates are named "ahb" and apb"
- the (main) clocks are named "mmc", "usb0_phy" and "ir"
There is no "bus" nor "mod".
> > > > > > +
> > > > > > +- resets: phandle to the reset of the device
> > > > > > +
> > > > > > +- ports: phandle's to the LCD ports
> > > > >
> > > > > Please use the OF graph.
> > > >
> > > > These ports are references to the graph of nodes. See
> > > > http://www.kernelhub.org/?msg=911825&p=2
> > >
> > > In an OF-graph, your phandle to the LCD controller would be replaced
> > > by an output endpoint.
> >
> > This is the DE controller. There is no endpoint link at this level.
>
> The display engine definitely has an endpoint: the TCON.
Not at all. The video chain is simply
CRTC (TCON) -> connector (HDMI/LCD/DAC/..)
The DE is an ancillary device which handles the planes.
> > The Device Engine just handles the planes of the LCDs, but, indeed,
> > the LCDs must know about the DE and the DE must know about the LCDs.
> > There are 2 ways to realize this knowledge in the DT:
> > 1) either the DE has one or two phandle's to the LCDs,
> > 2) or the LCDs have a phandle to the DE.
> >
> > I chose the 1st way, the DE ports pointing to the endpoint of the LCDs
> > which is part of the video link (OF-graph LCD <-> connector).
> > It would be possible to have phandles to the LCDs themselves, but this
> > asks for more code.
> >
> > The second way is also possible, but it also complexifies a bit the
> > exchanges DE <-> LCD.
>
> I'm still not sure how it would complexify anything, and why you can't
> use the display graph to model the relation between the display engine
> and the TCON (and why you want to use a generic property that refers
> to the of-graph while it really isn't).
Complexification:
1- my solution:
At startup time, the DE device is the DRM device. It has to know the
devices entering in the video chains.
The CRTCs (LCD/TCON) are found by
ports[i] -> parent
The connectors are found by
ports[i] -> endpoint -> remote_endpoint -> parent
2- with ports pointing to the LCDs:
The CRTCs (LCD/TCON) are simply
ports[i]
The connectors are found by
loop on all ports of ports[i]
ports[i][j] -> endpoint -> remote_endpoint -> parent
3- with a phandle to the DE in the LCDs:
The DE cannot be the DRM device because there is no information about
the video devices in the DT. Then, the DRM devices are the LCDs.
These LCDs must give their indices to the DE. So, the DE must implement
some callback function to accept a LCD definition, and there must be
a list of DEs in the driver to make the association DE <-> LCD[i]
Some more problem may be raised if a user wants to have the same frame
buffer on the 2 LCDs of a DE.
Anyway, my solution is already used in the IMX Soc.
See 'display-subsystem' in arch/arm/boot/dts/imx6q.dtsi for an example.
> > > > > > +void de2_disable_vblank(struct drm_device *drm, unsigned crtc)
> > > > > > +{
> > > > > > + struct priv *priv = drm->dev_private;
> > > > > > + struct lcd *lcd = priv->lcds[crtc];
> > > > > > +
> > > > > > + tcon_write(lcd->mmio, gint0,
> > > > > > + tcon_read(lcd->mmio, gint0) &
> > > > > > + ~TCON_GINT0_TCON1_Vb_Int_En);
> > > > > > +}
> > > > > > +
> > > > > > +/* panel functions */
> > > > >
> > > > > Panel functions? In the CRTC driver?
> > > >
> > > > Yes, dumb panel.
> > >
> > > What do you mean by that? Using a Parallel/RGB interface?
> >
> > Sorry, I though this was a well-known name. The 'dump panel' was used
> > in the documentation of my previous ARM machine as the video frame sent
> > to the HDMI controller. 'video_frame' is OK for you?
>
> If it's the frame sent to the encoder, then it would be the CRTC by
> DRM's nomenclature.
The CRTC is a software entity. The frame buffer is a hardware entity.
> > > > > > +static const struct {
> > > > > > + char chan;
> > > > > > + char layer;
> > > > > > + char pipe;
> > > > > > +} plane2layer[DE2_N_PLANES] = {
> > > > > > + [DE2_PRIMARY_PLANE] = {0, 0, 0},
> > > > > > + [DE2_CURSOR_PLANE] = {1, 0, 1},
> > > > > > + [DE2_VI_PLANE] = {0, 1, 0},
> > > > > > +};
[snip]
> > > > >
> > > > > Comments?
> > > >
> > > > This
> > > > primary plane is channel 0 (VI), layer 0, pipe 0
> > > > cursor plane is channel 1 (UI), layer 0, pipe 1
> > > > overlay plane is channel 0 (VI), layer 1, pipe 0
> > > > or the full explanation:
> > > > Constraints:
> > > > The VI channels can do RGB or YUV, while UI channels can do RGB
> > > > only.
> > > > The LCD 0 has 1 VI channel and 4 UI channels, while
> > > > LCD 1 has only 1 VI channel and 1 UI channel.
> > > > The cursor must go to a channel bigger than the primary channel,
> > > > otherwise it is not transparent.
> > > > First try:
> > > > Letting the primary plane (usually RGB) in the 2nd channel (UI),
> > > > as this is done in the legacy driver, asks for the cursor to go
> > > > to the next channel (UI), but this one does not exist in LCD1.
> > > > Retained layout:
> > > > So, we must use only 2 channels for the same behaviour on LCD0
> > > > (H3) and LCD1 (A83T)
> > > > The retained combination is:
> > > > - primary plane in the first channel (VI),
> > > > - cursor plane inthe 2nd channel (UI), and
> > > > - overlay plane in the 1st channel (VI).
> > > >
> > > > Note that there could be 3 overlay planes (a channel has 4
> > > > layers), but I am not sure that the A83T or the H3 could
> > > > support 3 simultaneous video streams...
> > >
> > > Do you know if the pipe works in the old display engine?
> > >
> > > Especially about the two-steps composition that wouldn't allow you to
> > > have alpha on all the planes?
> > >
> > > If it is similar, I think hardcoding the pipe number is pretty bad,
> > > because that would restrict the combination of planes and formats,
> > > while some other might have worked.
> >
> > From what I understood about the DE2, the pipes just define the priority
> > of the overlay channels (one pipe for one channel).
> > With the cursor constraint, there must be at least 2 channels in
> > order (primary, cursor). Then, with these 2 channels/pipes, there can be
> > 6 so-called overlay planes (3 RGB/YUV and 3 RGB only).
> > Enabling the pipes 2 and 3 (LCD 0 only) would offer 8 more planes, but
> > RGB only. Then, it might be useful to have dynamic pipes.
>
> That's very valuable (and definitely should go into a comment),
> thanks!
>
> I still believe that's it should be into a (simple at first)
> atomic_check. That would be easier to extend and quite easy to
> document and get simply by looking at the code.
Sorry for I don't understand what you mean.
> > > > > > +static int __init de2_drm_init(void)
> > > > > > +{
> > > > > > + int ret;
> > > > > > +
> > > > > > +/* uncomment to activate the drm traces at startup time */
> > > > > > +/* drm_debug = DRM_UT_CORE | DRM_UT_DRIVER | DRM_UT_KMS |
> > > > > > + DRM_UT_PRIME | DRM_UT_ATOMIC; */
> > > > >
> > > > > That's useless.
> > > >
> > > > Right, but it seems that some people don't know how to debug a DRM
> > > > driver. This is only a reminder.
> > > >
> > > > > > + DRM_DEBUG_DRIVER("\n");
> > > > > > +
> > > > > > + ret = platform_driver_register(&de2_lcd_platform_driver);
> > > > > > + if (ret < 0)
> > > > > > + return ret;
> > > > > > +
> > > > > > + ret = platform_driver_register(&de2_drm_platform_driver);
> > > > > > + if (ret < 0)
> > > > > > + platform_driver_unregister(&de2_lcd_platform_driver);
> > > > > > +
> > > > > > + return ret;
> > > > > > +}
> > > > >
> > > > > And that really shouldn't be done that way.
> > > >
> > > > May you explain?
> > >
> > > This goes against the whole idea of the device and driver
> > > model. Drivers should only register themselves, device should be
> > > created by buses (or by using some external components if the bus
> > > can't: DT, ACPI, etc.). If there's a match, you get probed.
> > >
> > > A driver that creates its own device just to probe itself violates
> > > that.
> >
> > In this function (module init), there is no driver yet.
> > The module contains 2 drivers: the DE (planes) and the LCD (CRTC),
> > and there is no macro to handle such modules.
>
> Ah, yes, my bad. I thought you were registering a device and a
> driver. Still this is a very unusual pattern. Why do you need to split
> the two? Can't you just merge them?
The DE and the LCDs are different devices on different drivers.
A DE must be only one device because it has to handle concurent
accesses from its 2 LCDs. Then 2 drivers.
But only one module. Why? Because there cannot be double direction
calls from one module to an other one, and, in our case, for example,
- the DRM (DE) device must call vblank functions which are handled in
the CRTC (TCON) device, and
- the CRTC device must call DE initialization functions at startup time.
> > > > > > +int de2_plane_init(struct drm_device *drm, struct lcd *lcd)
> > > > > > +{
> > > > > > + int ret, possible_crtcs = 1 << lcd->crtc_idx;
> > > > > > +
> > > > > > + ret = de2_one_plane_init(drm, &lcd->planes[DE2_PRIMARY_PLANE],
> > > > > > + DRM_PLANE_TYPE_PRIMARY, possible_crtcs,
> > > > > > + ui_formats, ARRAY_SIZE(ui_formats));
> > > > > > + if (ret >= 0)
> > > > > > + ret = de2_one_plane_init(drm, &lcd->planes[DE2_CURSOR_PLANE],
> > > > > > + DRM_PLANE_TYPE_CURSOR, possible_crtcs,
> > > > > > + ui_formats, ARRAY_SIZE(ui_formats));
> > > > >
> > > > > Nothing looks really special about that cursor plane. Any reasion not
> > > > > to make it an overlay?
> > > >
> > > > As explained above (channel/layer/pipe plane definitions), the cursor
> > > > cannot go in a channel lower or equal to the one of the primary plane.
> > > > Then, it must be known and, so, have an explicit plane.
> > >
> > > If you were to make it a plane, you could use atomic_check to check
> > > this and make sure this doesn't happen. And you would gain a generic
> > > plane that can be used for other purposes if needed.
> >
> > The function drm_crtc_init_with_planes() offers a cursor plane for free.
> > On the other side, having 6 overlay planes is more than the SoCs can
> > support.
>
> It's not really for free, it costs you a generic plane that could
> definitely be used for something else and cannot anymore because
> they've been hardcoded to a cursor.
>
> And having a camera, the VPU or even an application directly output
> directly into one of these planes seems a much better use of a generic
> plane than a cursor.
Looking at the harder case (A83T), there may be 8 planes on 2 channels.
Using a primary plane and the cursor,
8 planes - primary plane - cursor plane = 6 planes
6 planes are available.
If I count correctly, in your example:
one camera + one VPU + one application = 3 planes
3 planes are used.
So, 3 planes are still available.
On the other side, removing the cursor would just let one more plane.
Do we really need this one? In other words, I'd be pleased to know how
you run 7 applications doing video overlay.
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ 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