* [PATCH v3 2/2] ARM64: dts: meson-gxbb: add MMC support
From: Rob Herring @ 2016-09-23 13:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160914004314.682-3-khilman@baylibre.com>
On Tue, Sep 13, 2016 at 05:43:14PM -0700, Kevin Hilman wrote:
> Add binding and basic support for the SD/eMMC controller on Amlogic
> S905/GXBB devices.
>
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
> ---
> .../devicetree/bindings/mmc/amlogic,meson-gxbb.txt | 29 ++++++++
> .../arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 87 ++++++++++++++++++++++
> arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi | 78 +++++++++++++++++++
> arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 37 ++++++++-
> 4 files changed, 230 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/mmc/amlogic,meson-gxbb.txt
Some nits below, otherwise:
Acked-by: Rob Herring <robh@kernel.org>
>
> diff --git a/Documentation/devicetree/bindings/mmc/amlogic,meson-gxbb.txt b/Documentation/devicetree/bindings/mmc/amlogic,meson-gxbb.txt
> new file mode 100644
> index 000000000000..39cbe528b7de
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/amlogic,meson-gxbb.txt
> @@ -0,0 +1,29 @@
> +Amlogic SD / eMMC controller for S905/GXBB family SoCs
> +
> +The MMC 5.1 compliant host controller on Amlogic provides the
> +interface for SD, eMMC and SDIO devices.
> +
> +This file documents the properties in addition to those available in
> +the MMC core bindings, documented by mmc.txt.
> +
> +Required properties:
> +- compatible : contains "amlogic,meson-gxbb-mmc"
> +- clocks : A list of phandle + clock-specifier pairs for the clocks listed in clock-names.
> +- clock-names: Should contain the following:
> + "core" - Main peripheral bus clock
> + "clkin0" - Parent clock of internal mux
> + "clkin1" - Other parent clock of internal mux
> + The driver has an interal mux clock which switches between clkin0 and clkin1 depending on the
> + clock rate requested by the MMC core.
> +
> +Example:
> +
> + sd_emmc_a: mmc at 70000 {
> + compatible = "amlogic,meson-gxbb-mmc";
> + reg = <0x0 0x70000 0x0 0x2000>;
> + interrupts = < GIC_SPI 216 IRQ_TYPE_EDGE_RISING>;
> + clocks = <&clkc CLKID_SD_EMMC_A>, <&xtal>, <&clkc CLKID_FCLK_DIV2>;
> + clock-names = "core", "clkin0", "clkin1";
> + pinctrl-0 = <&emmc_pins>;
> + };
> +
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> index 90a84c514d3d..2a9303e7fab8 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts
> @@ -73,6 +73,56 @@
> default-state = "off";
> };
> };
> +
> + tflash_vdd: regulator-tflash_vdd {
Use '-' not '_' in node names.
> + /*
> + * signal name from schematics: TFLASH_VDD_EN
> + */
> + compatible = "regulator-fixed";
> +
> + regulator-name = "TFLASH_VDD";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> +
> + gpio = <&gpio_ao GPIOAO_12 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + };
> +
> + tf_io: gpio-regulator-tf_io {
ditto
> + compatible = "regulator-gpio";
> +
> + regulator-name = "TF_IO";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> +
> + /*
> + * signal name from schematics: TF_3V3N_1V8_EN
> + */
> + gpios = <&gpio_ao GPIOAO_3 GPIO_ACTIVE_HIGH>;
> + gpios-states = <0>;
> +
> + states = <3300000 0
> + 1800000 1>;
> + };
> +
> + vcc1v8: regulator-vcc1v8 {
> + compatible = "regulator-fixed";
> + regulator-name = "VCC1V8";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + };
> +
> + vcc3v3: regulator-vcc3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "VCC3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + };
> +
> + emmc_pwrseq: emmc-pwrseq {
> + compatible = "mmc-pwrseq-emmc";
> + reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>;
> + };
> };
>
> &uart_AO {
> @@ -87,3 +137,40 @@
> pinctrl-names = "default";
> };
>
> +/* SD */
> +&sd_emmc_b {
> + status = "okay";
> + pinctrl-0 = <&sdcard_pins>;
> + pinctrl-names = "default";
> +
> + bus-width = <4>;
> + cap-sd-highspeed;
> + max-frequency = <100000000>;
> + disable-wp;
> +
> + cd-gpios = <&gpio CARD_6 GPIO_ACTIVE_HIGH>;
> + cd-inverted;
> +
> + vmmc-supply = <&tflash_vdd>;
> + vqmmc-supply = <&tf_io>;
> +};
> +
> +/* eMMC */
> +&sd_emmc_c {
> + status = "okay";
> + pinctrl-0 = <&emmc_pins>;
> + pinctrl-names = "default";
> +
> + bus-width = <8>;
> + cap-sd-highspeed;
> + max-frequency = <200000000>;
> + non-removable;
> + disable-wp;
> + cap-mmc-highspeed;
> + mmc-ddr-1_8v;
> + mmc-hs200-1_8v;
> +
> + mmc-pwrseq = <&emmc_pwrseq>;
> + vmmc-supply = <&vcc3v3>;
> + vqmmc-supply = <&vcc1v8>;
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> index f4f30f674b4c..77c4d5eb48a2 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb-p20x.dtsi
> @@ -57,6 +57,47 @@
> device_type = "memory";
> reg = <0x0 0x0 0x0 0x40000000>;
> };
> +
> + vddio_card: gpio-regulator {
> + compatible = "regulator-gpio";
> +
> + regulator-name = "VDDIO_CARD";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <3300000>;
> +
> + gpios = <&gpio_ao GPIOAO_5 GPIO_ACTIVE_HIGH>;
> + gpios-states = <1>;
> +
> + /* Based on P200 schematics, signal CARD_1.8V/3.3V_CTR */
> + states = <1800000 0
> + 3300000 1>;
> + };
> +
> + vddio_boot: regulator-vddio_boot {
ditto
> + compatible = "regulator-fixed";
> + regulator-name = "VDDIO_BOOT";
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + };
> +
> + vddao_3v3: regulator-vddao_3v3 {
ditto
> + compatible = "regulator-fixed";
> + regulator-name = "VDDAO_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + };
> +
> + vcc_3v3: regulator-vcc_3v3 {
ditto
> + compatible = "regulator-fixed";
> + regulator-name = "VCC_3V3";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + };
> +
> + emmc_pwrseq: emmc-pwrseq {
> + compatible = "mmc-pwrseq-emmc";
> + reset-gpios = <&gpio BOOT_9 GPIO_ACTIVE_LOW>;
> + };
> };
>
> /* This UART is brought out to the DB9 connector */
> @@ -72,3 +113,40 @@
> pinctrl-names = "default";
> };
>
> +/* SD card */
> +&sd_emmc_b {
> + status = "okay";
> + pinctrl-0 = <&sdcard_pins>;
> + pinctrl-names = "default";
> +
> + bus-width = <4>;
> + cap-sd-highspeed;
> + max-frequency = <100000000>;
> + disable-wp;
> +
> + cd-gpios = <&gpio CARD_6 GPIO_ACTIVE_HIGH>;
> + cd-inverted;
> +
> + vmmc-supply = <&vddao_3v3>;
> + vqmmc-supply = <&vddio_card>;
> +};
> +
> +/* eMMC */
> +&sd_emmc_c {
> + status = "okay";
> + pinctrl-0 = <&emmc_pins>;
> + pinctrl-names = "default";
> +
> + bus-width = <8>;
> + cap-sd-highspeed;
> + cap-mmc-highspeed;
> + max-frequency = <200000000>;
> + non-removable;
> + disable-wp;
> + mmc-ddr-1_8v;
> + mmc-hs200-1_8v;
> +
> + mmc-pwrseq = <&emmc_pwrseq>;
> + vmmc-supply = <&vcc_3v3>;
> + vqmmc-supply = <&vddio_boot>;
> +};
> diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> index e502c24b0ac7..3723007146ac 100644
> --- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> +++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
> @@ -45,6 +45,7 @@
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> #include <dt-bindings/gpio/meson-gxbb-gpio.h>
> #include <dt-bindings/reset/amlogic,meson-gxbb-reset.h>
> +#include <dt-bindings/clock/gxbb-clkc.h>
>
> / {
> compatible = "amlogic,meson-gxbb";
> @@ -246,7 +247,8 @@
> mux {
> groups = "emmc_nand_d07",
> "emmc_cmd",
> - "emmc_clk";
> + "emmc_clk",
> + "emmc_ds";
> function = "emmc";
> };
> };
> @@ -329,6 +331,39 @@
> #address-cells = <2>;
> #size-cells = <2>;
> ranges = <0x0 0x0 0x0 0xd0000000 0x0 0x200000>;
> +
> + sd_emmc_a: mmc at 70000 {
> + compatible = "amlogic,meson-gxbb-mmc";
> + reg = <0x0 0x70000 0x0 0x2000>;
> + interrupts = <GIC_SPI 216 IRQ_TYPE_EDGE_RISING>;
> + clocks = <&clkc CLKID_SD_EMMC_A>,
> + <&xtal>,
> + <&clkc CLKID_FCLK_DIV2>;
> + clock-names = "core", "clkin0", "clkin1";
> + status = "disabled";
> + };
> +
> + sd_emmc_b: mmc at 72000 {
> + compatible = "amlogic,meson-gxbb-mmc";
> + reg = <0x0 0x72000 0x0 0x2000>;
> + interrupts = <GIC_SPI 217 IRQ_TYPE_EDGE_RISING>;
> + clocks = <&clkc CLKID_SD_EMMC_B>,
> + <&xtal>,
> + <&clkc CLKID_FCLK_DIV2>;
> + clock-names = "core", "clkin0", "clkin1";
> + status = "disabled";
> + };
> +
> + sd_emmc_c: mmc at 74000 {
> + compatible = "amlogic,meson-gxbb-mmc";
> + reg = <0x0 0x74000 0x0 0x2000>;
> + interrupts = <GIC_SPI 218 IRQ_TYPE_EDGE_RISING>;
> + clocks = <&clkc CLKID_SD_EMMC_C>,
> + <&xtal>,
> + <&clkc CLKID_FCLK_DIV2>;
> + clock-names = "core", "clkin0", "clkin1";
> + status = "disabled";
> + };
> };
>
> ethmac: ethernet at c9410000 {
> --
> 2.9.3
>
^ permalink raw reply
* [PATCH] drm/sun4i: rgb: Enable panel after controller
From: Jonathan Liu @ 2016-09-23 13:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923131626.GX8719@lukather>
Hi Maxime,
On 23 September 2016 at 23:16, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Thu, Sep 22, 2016 at 08:03:31AM +1000, Jonathan Liu wrote:
>> Hi Maxime,
>>
>> On Thursday, 22 September 2016, Maxime Ripard <maxime.ripard@free-electrons.
>> com> wrote:
>>
>> > On Wed, Sep 21, 2016 at 11:03:04PM +1000, Jonathan Liu wrote:
>> > > The panel should be enabled after the controller so that the panel
>> > > prepare/enable delays are properly taken into account. Similarly, the
>> > > panel should be disabled before the controller so that the panel
>> > > unprepare/disable delays are properly taken into account.
>> > >
>> > > This is useful for avoiding visual glitches.
>> >
>> > This is not really taking any delays into account, especially since
>> > drm_panel_enable and prepare are suppose to block until their
>> > operation is complete.
>>
>>
>> drm_panel_prepare turns on power to the LCD using enable-gpios property of
>> the panel and then blocks for prepare delay. The prepare delay for panel
>> can be set to how long it takes between the time the panel is powered to
>> when it is ready to receive images. If backlight property is specified the
>> backlight will be off while the panel is powered on.
>>
>> drm_panel_enable blocks for enable delay and then turns on the backlight.
>> The enable delay can be set to how long it takes for panel to start making
>> the image visible after receiving the first valid frame. For example if the
>> panel starts off as white and the TFT takes some time to initialize to
>> black before it shows the image being received.
>>
>> Refer to drivers/gpu/drm/panel-panel.simple.c for details.
>
> From drm_panel.h:
>
> """
> * drm_panel_enable - enable a panel
> * @panel: DRM panel
> *
> * Calling this function will cause the panel display drivers to be turned on
> * and the backlight to be enabled. Content will be visible on screen after
> * this call completes.
> """
>
> """
> * drm_panel_prepare - power on a panel
> * @panel: DRM panel
> *
> * Calling this function will enable power and deassert any reset signals to
> * the panel. After this has completed it is possible to communicate with any
> * integrated circuitry via a command bus.
> """
>
> Those comments clearly says that the caller should not have to deal
> with the delays, even more so by just moving calls around and hoping
> that the code running in between is adding enough delay for the panel
> to behave properly.
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/drm/drm_panel.h#n34
In comment for struct drm_panel_funcs:
/**
* struct drm_panel_funcs - perform operations on a given panel
* @disable: disable panel (turn off back light, etc.)
* @unprepare: turn off panel
* @prepare: turn on panel and perform set up
* @enable: enable panel (turn on back light, etc.)
* @get_modes: add modes to the connector that the panel is attached to and
* return the number of modes added
* @get_timings: copy display timings into the provided array and return
* the number of display timings available
*
* The .prepare() function is typically called before the display controller
* starts to transmit video data. Panel drivers can use this to turn the panel
* on and wait for it to become ready. If additional configuration is required
* (via a control bus such as I2C, SPI or DSI for example) this is a good time
* to do that.
*
* After the display controller has started transmitting video data, it's safe
* to call the .enable() function. This will typically enable the backlight to
* make the image on screen visible. Some panels require a certain amount of
* time or frames before the image is displayed. This function is responsible
* for taking this into account before enabling the backlight to avoid visual
* glitches.
*
* Before stopping video transmission from the display controller it can be
* necessary to turn off the panel to avoid visual glitches. This is done in
* the .disable() function. Analogously to .enable() this typically involves
* turning off the backlight and waiting for some time to make sure no image
* is visible on the panel. It is then safe for the display controller to
* cease transmission of video data.
*
* To save power when no video data is transmitted, a driver can power down
* the panel. This is the job of the .unprepare() function.
*/
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/panel/panel-simple.c?id=refs/tags/v4.8-rc7#n39
In struct panel_desc:
/**
* @prepare: the time (in milliseconds) that it takes for the panel to
* become ready and start receiving video data
* @enable: the time (in milliseconds) that it takes for the panel to
* display the first valid frame after starting to receive
* video data
* @disable: the time (in milliseconds) that it takes for the panel to
* turn the display off (no content is visible)
* @unprepare: the time (in milliseconds) that it takes for the panel
* to power itself down completely
*/
Regards,
Jonathan
^ permalink raw reply
* [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on Hip06
From: Arnd Bergmann @ 2016-09-23 13:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <EE11001F9E5DDD47B7634E2F8A612F2E1F8842B6@lhreml507-mbx>
On Friday, September 23, 2016 10:23:30 AM CEST Gabriele Paoloni wrote:
> Hi Arnd
>
> > -----Original Message-----
> > From: Arnd Bergmann [mailto:arnd at arndb.de]
> > Sent: 23 September 2016 10:52
> > To: zhichang.yuan
> > Cc: Gabriele Paoloni; linux-arm-kernel at lists.infradead.org;
> > devicetree at vger.kernel.org; lorenzo.pieralisi at arm.com; minyard at acm.org;
> > linux-pci at vger.kernel.org; gregkh at linuxfoundation.org; John Garry;
> > will.deacon at arm.com; linux-kernel at vger.kernel.org; Yuanzhichang;
> > Linuxarm; xuwei (O); linux-serial at vger.kernel.org;
> > benh at kernel.crashing.org; zourongrong at gmail.com; liviu.dudau at arm.com;
> > kantyzc at 163.com
> > Subject: Re: [PATCH V3 2/4] ARM64 LPC: LPC driver implementation on
> > Hip06
> >
> > On Friday, September 23, 2016 12:27:17 AM CEST zhichang.yuan wrote:
> > > For this patch sketch, I have a question.
> > > Do we call pci_address_to_pio in arch_of_address_to_pio to get the
> > > corresponding logical IO port
> > > for LPC??
> >
> >
> > No, of course not, that would be silly:
> >
> > The argument to pci_address_to_pio() is a phys_addr_t, and we we don't
> > have one because there is no address associated with your PIO, that
> > is the entire point of your driver!
> >
> > Also, we already know the mapping because this is what the inb/outb
> > workaround is looking at, so there is absolutely no reason to call it
> > either.
>
> Ok assume that we do not call pci_address_to_pio() for the ISA bus...
> The LPC driver will register its phys address range in io_range_list,
> then the IPMI driver probe will retrieve its physical address calling
> of_address_to_resource and will use the indirect io to access this
> address.
>
> From the perspective of the indirect IO function the input parameter
> is an unsigned long addr that (now) can be either:
> 1) an IO token coming from a legacy pci device
> 2) a phys address that lives on the LPC bus
>
> These are conceptually two separate address spaces (and actually they
> both start from 0).
Why? Any IORESOURCE_IO address always refers to the logical I/O port
range in Linux, not the physical address that is used on a bus.
> If the input parameter can live on different address spaces that are
> overlapped, even if I save the used LPC range in arm64_extio_ops->start/end
> there is no way for the indirect IO to tell if the input parameter is
> an I/O token or a phys address that belongs to LPC...
The start address is the offset: if you get an address between 'start'
and 'end', you subtract the 'start' from it, and use that to call
the registered driver function. That works because we can safely
assume that the bus address range that the LPC driver registers starts
zero.
Arnd
^ permalink raw reply
* [PATCH v2 2/3] musb: sunxi: Remove custom babble handling
From: Hans de Goede @ 2016-09-23 13:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160922143050.GC31827@uda0271908>
Hi,
On 09/22/2016 05:30 PM, Bin Liu wrote:
> Hi,
>
> On Thu, Sep 22, 2016 at 05:03:39PM +0300, Hans de Goede wrote:
>> Hi,
>>
>> On 09/22/2016 04:54 PM, Bin Liu wrote:
>>> Hi,
>>>
>>> On Thu, Sep 22, 2016 at 02:19:00PM +0300, Hans de Goede wrote:
>>>> The musb-core now a days always treats babble errors in host mode
>>>
>>> I don't think this statement is accurate. You might want to change it to
>>> "The musb core already handles babble interrupt" or something else.
>>
>> It is accurate if you look in the history at drivers/usb/musb
>> commits around 15-03-10 you will see 2 relevant commits:
>>
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/usb/musb?id=b4dc38fd45b63e3da2bc98db5d283a15a637a2fa
>>
>> "usb: musb: core: simplify musb_recover_work()"
>>
>> This commits introduces calling musb_root_disconnect(musb)
>> on babble errors, that was not happening before which is why
>
> That is true, but calling musb_root_disconnect() is just one step of the
> recovery in musb core, not all.
>
> The statement of "treats babble errors in host mode as disconnects"
> implies all the babble handling is just disconnect, which is not
> accurate.
Ok, I'll send out a v3 with an improved commit msg.
> BTY, "babble errors in host mode" is also redundant. babble implies
> host mode.
Regards,
Hans
>
> Regards,
> -Bin.
>> I added the custom babble error handling. to the sunxi glue.
>>
>> And:
>>
>> "usb: musb: core: always try to recover from babble"
>>
>> Where the title says it all.
>>
>> Take these together and I believe that my commit msg:
>>
>> "The musb-core now a days always treats babble errors in host mode
>> as disconnects, so there is no need for the sunxi specific handling
>> of this anymore."
>>
>> Is quite accurate.
>>
>> Regards,
>>
>> Hans
>>
>>
>>>>
>>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>>>> ---
>>>> Changes in v2:
>>>> -This is a new patch in v2 of this patch series
>>>> ---
>>>> drivers/usb/musb/sunxi.c | 10 ----------
>>>> 1 file changed, 10 deletions(-)
>>>>
>>>> diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
>>>> index 1408245..82eba92 100644
>>>> --- a/drivers/usb/musb/sunxi.c
>>>> +++ b/drivers/usb/musb/sunxi.c
>>>> @@ -186,16 +186,6 @@ static irqreturn_t sunxi_musb_interrupt(int irq, void *__hci)
>>>> if (musb->int_usb)
>>>> writeb(musb->int_usb, musb->mregs + SUNXI_MUSB_INTRUSB);
>>>>
>>>> - /*
>>>> - * sunxi musb often signals babble on low / full speed device
>>>> - * disconnect, without ever raising MUSB_INTR_DISCONNECT, since
>>>> - * normally babble never happens treat it as disconnect.
>>>> - */
>>>> - if ((musb->int_usb & MUSB_INTR_BABBLE) && is_host_active(musb)) {
>>>> - musb->int_usb &= ~MUSB_INTR_BABBLE;
>>>> - musb->int_usb |= MUSB_INTR_DISCONNECT;
>>>> - }
>>>> -
>>>> if ((musb->int_usb & MUSB_INTR_RESET) && !is_host_active(musb)) {
>>>> /* ep0 FADDR must be 0 when (re)entering peripheral mode */
>>>> musb_ep_select(musb->mregs, 0);
>>>> --
>>>> 2.9.3
>>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms
From: Sudeep Holla @ 2016-09-23 13:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c6697a9c-013b-9880-e52f-8de2f0a5b7ae@arm.com>
On 23/09/16 14:18, Robin Murphy wrote:
> On 23/09/16 14:13, Stuart Yoder wrote:
>>
>>
[...]
>>
>> Which arch/arm/mach-* platform are you using for Juno?
>
> I don't even know! :) I just start with a multi_v7_defconfig plus a few
> extra bits (LPAE, KVM, sil24, sky2, etc.) and it works. I guess it's the
> combination of mach-vexpress and mach-virt.
>
It should be matching "arm,vexpress" and just using mach-vexpress/v2m.c
as it's present as compatible in Juno DT but nothing else there.
mach-virt was deleted and we just have "Generic DT based system" in
arch/arm/kernel/devtree.c which IIUC doesn't require any compatible in
the DT. So dropping "arm,vexpress" will make it use "Generic DT based
system" I believe.
--
Regards,
Sudeep
^ permalink raw reply
* [PATCH v3 3/3] musb: sunxi: Force session end on babble errors in host-mode
From: Hans de Goede @ 2016-09-23 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923134058.26828-1-hdegoede@redhat.com>
The sunxi musb has a bug where sometimes it will generate a babble
error on device disconnect instead of a disconnect irq. When this
happens the musb-controller switches from host mode to device mode
(it clears MUSB_DEVCTL_SESSION and sets MUSB_DEVCTL_BDEVICE) and
gets stuck in this state.
Clearing this requires reporting Vbus low for 200 or more ms, but
on some devices Vbus is simply always high (host-only mode, no Vbus
control).
This commit adds a sunxi_musb_recover() callback which makes
sunxi_musb_work call phy_set_mode with the current mode, which
will force end the current session.
This fixes the musb controller getting stuck in this state on systems
without Vbus control; and also fixes the need to unplug the usb-b ->
usb-a cable to get out of this state on systems with Vbus control.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Changes in v2:
-Use musb_platform_recover callback instead of using DYI code in the
interrupt handler
-Call phy_set_mode with the current mode instead of adding a new custom
sunxi phy callback
---
drivers/usb/musb/sunxi.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
index 82eba92..d0be0ea 100644
--- a/drivers/usb/musb/sunxi.c
+++ b/drivers/usb/musb/sunxi.c
@@ -380,6 +380,20 @@ static int sunxi_musb_set_mode(struct musb *musb, u8 mode)
return 0;
}
+static int sunxi_musb_recover(struct musb *musb)
+{
+ struct sunxi_glue *glue = dev_get_drvdata(musb->controller->parent);
+
+ /*
+ * Schedule a phy_set_mode with the current glue->phy_mode value,
+ * this will force end the current session.
+ */
+ set_bit(SUNXI_MUSB_FL_PHY_MODE_PEND, &glue->flags);
+ schedule_work(&glue->work);
+
+ return 0;
+}
+
/*
* sunxi musb register layout
* 0x00 - 0x17 fifo regs, 1 long per fifo
@@ -608,6 +622,7 @@ static const struct musb_platform_ops sunxi_musb_ops = {
.dma_init = sunxi_musb_dma_controller_create,
.dma_exit = sunxi_musb_dma_controller_destroy,
.set_mode = sunxi_musb_set_mode,
+ .recover = sunxi_musb_recover,
.set_vbus = sunxi_musb_set_vbus,
.pre_root_reset_end = sunxi_musb_pre_root_reset_end,
.post_root_reset_end = sunxi_musb_post_root_reset_end,
--
2.9.3
^ permalink raw reply related
* [PATCH v3 2/3] musb: sunxi: Remove custom babble handling
From: Hans de Goede @ 2016-09-23 13:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923134058.26828-1-hdegoede@redhat.com>
The musb core already handles babble interrupts, so the sunxi glue
having its own custom handling is redundant.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Changes in v2:
-This is a new patch in v2 of this patch series
Changes in v3:
-Improve commit msg
---
drivers/usb/musb/sunxi.c | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c
index 1408245..82eba92 100644
--- a/drivers/usb/musb/sunxi.c
+++ b/drivers/usb/musb/sunxi.c
@@ -186,16 +186,6 @@ static irqreturn_t sunxi_musb_interrupt(int irq, void *__hci)
if (musb->int_usb)
writeb(musb->int_usb, musb->mregs + SUNXI_MUSB_INTRUSB);
- /*
- * sunxi musb often signals babble on low / full speed device
- * disconnect, without ever raising MUSB_INTR_DISCONNECT, since
- * normally babble never happens treat it as disconnect.
- */
- if ((musb->int_usb & MUSB_INTR_BABBLE) && is_host_active(musb)) {
- musb->int_usb &= ~MUSB_INTR_BABBLE;
- musb->int_usb |= MUSB_INTR_DISCONNECT;
- }
-
if ((musb->int_usb & MUSB_INTR_RESET) && !is_host_active(musb)) {
/* ep0 FADDR must be 0 when (re)entering peripheral mode */
musb_ep_select(musb->mregs, 0);
--
2.9.3
^ permalink raw reply related
* [PATCH v3 1/3] phy_sun4i_usb: set_mode: Allow using set_mode to force end the current session
From: Hans de Goede @ 2016-09-23 13:40 UTC (permalink / raw)
To: linux-arm-kernel
The sunxi musb has a bug where sometimes it will generate a babble
error on device disconnect instead of a disconnect irq. When this
happens the musb-controller switches from host mode to device mode
(it clears MUSB_DEVCTL_SESSION and sets MUSB_DEVCTL_BDEVICE) and
gets stuck in this state.
Clearing this requires reporting Vbus low for 200 or more ms, but
on some devices Vbus is simply always high (host-only mode, no Vbus
control).
This commit modifies sun4i_usb_phy_set_mode so that it will force
end the current session when called with the current mode, before this
commit calling set_mode with the current mode was a nop since id_det
would stay the same resulting in the detect_work not doing anything.
This allows the sunxi-musb glue to use sun4i_usb_phy_set_mode to force
end the current session without changing the mode, to fixup the stuck
state after a babble error.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Changes in v2:
-New patch in v2 of this series replacing the
"phy-sun4i-usb: Add sun4i_usb_phy_force_session_end() function"
from v1
Changes in v3:
-Fix dev_info so that it prints the new-mode instead of the old one
---
drivers/phy/phy-sun4i-usb.c | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
index 43c0d98..cbd338d 100644
--- a/drivers/phy/phy-sun4i-usb.c
+++ b/drivers/phy/phy-sun4i-usb.c
@@ -437,25 +437,31 @@ static int sun4i_usb_phy_set_mode(struct phy *_phy, enum phy_mode mode)
{
struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
+ int new_mode;
if (phy->index != 0)
return -EINVAL;
switch (mode) {
case PHY_MODE_USB_HOST:
- data->dr_mode = USB_DR_MODE_HOST;
+ new_mode = USB_DR_MODE_HOST;
break;
case PHY_MODE_USB_DEVICE:
- data->dr_mode = USB_DR_MODE_PERIPHERAL;
+ new_mode = USB_DR_MODE_PERIPHERAL;
break;
case PHY_MODE_USB_OTG:
- data->dr_mode = USB_DR_MODE_OTG;
+ new_mode = USB_DR_MODE_OTG;
break;
default:
return -EINVAL;
}
- dev_info(&_phy->dev, "Changing dr_mode to %d\n", (int)data->dr_mode);
+ if (new_mode != data->dr_mode) {
+ dev_info(&_phy->dev, "Changing dr_mode to %d\n", new_mode);
+ data->dr_mode = new_mode;
+ }
+
+ data->id_det = -1; /* Force reprocessing of id */
data->force_session_end = true;
queue_delayed_work(system_wq, &data->detect, 0);
--
2.9.3
^ permalink raw reply related
* [PATCH 2/3] firmware: dt: document lpc1850 boot ROM bindings
From: Rob Herring @ 2016-09-23 13:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160913195117.2887-3-manabian@gmail.com>
On Tue, Sep 13, 2016 at 09:51:16PM +0200, Joachim Eastwood wrote:
> Binding documentation for the NXP LPC boot ROM.
>
> Signed-off-by: Joachim Eastwood <manabian@gmail.com>
> ---
> .../devicetree/bindings/firmware/nxp,boot-rom.txt | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/firmware/nxp,boot-rom.txt
>
> diff --git a/Documentation/devicetree/bindings/firmware/nxp,boot-rom.txt b/Documentation/devicetree/bindings/firmware/nxp,boot-rom.txt
> new file mode 100644
> index 0000000..5f3a044
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/firmware/nxp,boot-rom.txt
> @@ -0,0 +1,21 @@
> +* NXP LPC boot ROM
> +
> +NXP LPC microcontrollers contains a boot ROM used to retrieve part information
> +and access internal Flash memory and OTP memory. Note that the Flash API is
> +not available on Flashless devices.
Is this determined at run-time? If not flashless devices should have a
different compatible string to determine this then.
> +
> +Required properties:
> +- compatible: must contain the following: "nxp,lpc1850-boot-rom".
> +- reg: physical base address of the ROM and length of memory mapped region.
> +- syscon: handle to NXP CREG (Configuration Registers) syscon block.
> +- nvmem-cells: = handle to OTP memory cell which contain the part ID.
> +- nvmem-cell-names: must contain "PartID".
> +
> +Example:
> +boot_rom: firmware at 10400000 {
> + compatible = "nxp,lpc1850-boot-rom";
> + reg = <0x10400000 0x10000>;
> + syscon = <&creg>;
> + nvmem-cells = <&part_id>;
> + nvmem-cell-names = "PartID";
> +};
> --
> 2.9.3
>
^ permalink raw reply
* [PATCH 2/3] nvmem: dt: document lpc1850 OTP binding
From: Rob Herring @ 2016-09-23 13:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160913161241.22492-3-manabian@gmail.com>
On Tue, Sep 13, 2016 at 06:12:40PM +0200, Joachim Eastwood wrote:
> Documenation for the LPC18xx/43xx OTP memory bindings.
>
> Signed-off-by: Joachim Eastwood <manabian@gmail.com>
> ---
> .../devicetree/bindings/nvmem/lpc1850-otp.txt | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/nvmem/lpc1850-otp.txt
>
> diff --git a/Documentation/devicetree/bindings/nvmem/lpc1850-otp.txt b/Documentation/devicetree/bindings/nvmem/lpc1850-otp.txt
> new file mode 100644
> index 0000000..853b6a7
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/nvmem/lpc1850-otp.txt
> @@ -0,0 +1,20 @@
> +* NXP LPC18xx OTP memory
> +
> +Internal OTP (One Time Programmable) memory for NXP LPC18xx/43xx devices.
> +
> +Required properties:
> + - compatible: Should be "nxp,lpc1850-otp"
> + - reg: Must contain an entry with the physical base address and length
> + for each entry in reg-names.
> + - address-cells: must be set to 1.
> + - size-cells: must be set to 1.
Not needed unless you have child nodes.
> +
> +See nvmem.txt for more information.
> +
> +Example:
> + otp: otp at 40045000 {
> + compatible = "nxp,lpc1850-otp";
> + reg = <0x40045000 0x1000>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + };
> --
> 2.9.3
>
^ permalink raw reply
* [PATCH v2] i2c: uniphier-f: fix misdetection of incomplete STOP condition
From: Masahiro Yamada @ 2016-09-23 13:34 UTC (permalink / raw)
To: linux-arm-kernel
Currently, the status register FI2C_SR is checked immediately after
a STOP condition is issued in case of the deferred STOP condition.
It takes typically 5-10 usec until the corresponding bits in the
register are set, so the error check for "stop condition was not
completed" is very likely to be false positive.
Add wait code to relax the status register check.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
---
Changes in v2:
- use readl_poll_timeout()
drivers/i2c/busses/i2c-uniphier-f.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-uniphier-f.c b/drivers/i2c/busses/i2c-uniphier-f.c
index 829df91..db9105e 100644
--- a/drivers/i2c/busses/i2c-uniphier-f.c
+++ b/drivers/i2c/busses/i2c-uniphier-f.c
@@ -14,6 +14,7 @@
#include <linux/clk.h>
#include <linux/i2c.h>
+#include <linux/iopoll.h>
#include <linux/interrupt.h>
#include <linux/io.h>
#include <linux/module.h>
@@ -348,14 +349,19 @@ static int uniphier_fi2c_master_xfer_one(struct i2c_adapter *adap,
dev_dbg(&adap->dev, "complete\n");
if (unlikely(priv->flags & UNIPHIER_FI2C_DEFER_STOP_COMP)) {
- u32 status = readl(priv->membase + UNIPHIER_FI2C_SR);
-
- if (!(status & UNIPHIER_FI2C_SR_STS) ||
- status & UNIPHIER_FI2C_SR_BB) {
+ u32 status;
+ int ret;
+
+ ret = readl_poll_timeout(priv->membase + UNIPHIER_FI2C_SR,
+ status,
+ (status & UNIPHIER_FI2C_SR_STS) &&
+ !(status & UNIPHIER_FI2C_SR_BB),
+ 1, 20);
+ if (ret) {
dev_err(&adap->dev,
"stop condition was not completed.\n");
uniphier_fi2c_recover(priv);
- return -EBUSY;
+ return ret;
}
}
--
1.9.1
^ permalink raw reply related
* [PATCH] i2c: uniphier-f: fix misdetection of incomplete STOP condition
From: Masahiro Yamada @ 2016-09-23 13:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923121245.GA1580@katana>
Hi Wolfram,
2016-09-23 21:12 GMT+09:00 Wolfram Sang <wsa@the-dreams.de>:
> On Fri, Sep 23, 2016 at 09:04:01PM +0900, Masahiro Yamada wrote:
>> Currently, the status register FI2C_SR is checked immediately after
>> a STOP condition is issued in case of the deferred STOP condition.
>> It takes typically 5-10 usec until the corresponding bits in the
>> register are set, so the error check for "stop condition was not
>> completed" is very likely to be false positive.
>>
>> Add wait code to relax the status register check.
>>
>> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
>
> Use readl_poll_timeout?
>
Yes, thanks for your advice!
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH 05/10][v3] dt-bindings: ahci-fsl-qoriq: updated for SoC ls1046a
From: Rob Herring @ 2016-09-23 13:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473754203-22970-6-git-send-email-shh.xie@gmail.com>
On Tue, Sep 13, 2016 at 04:09:58PM +0800, shh.xie at gmail.com wrote:
> From: Shaohui Xie <Shaohui.Xie@nxp.com>
>
> Signed-off-by: Shaohui Xie <Shaohui.Xie@nxp.com>
> ---
> change in V3:
> 1. new patch.
>
> Documentation/devicetree/bindings/ata/ahci-fsl-qoriq.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH v3] gpio: Added zynq specific check for special pins on bank zero
From: Linus Walleij @ 2016-09-23 13:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474630018-9986-1-git-send-email-navam@xilinx.com>
On Fri, Sep 23, 2016 at 1:26 PM, Nava kishore Manne
<nava.manne@xilinx.com> wrote:
> From: Nava kishore Manne <nava.manne@xilinx.com>
>
> This patch adds zynq specific check for bank 0 pins 7 and 8
> are special and cannot be used as inputs
>
> Signed-off-by: Nava kishore Manne <navam@xilinx.com>
> Reported-by: Jonas Karlsson <Jonas.d.karlsson@gmail.com>
> Acked-by: S?ren Brinkmann <soren.brinkmann@xilinx.com>
> Acked-by: Michal Simek <michal.simek@xilinx.com>
> ---
> Changes for v3:
> -Fixed some minor comments.
Patch applied.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms
From: Rob Herring @ 2016-09-23 13:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c6697a9c-013b-9880-e52f-8de2f0a5b7ae@arm.com>
On Fri, Sep 23, 2016 at 8:18 AM, Robin Murphy <robin.murphy@arm.com> wrote:
> On 23/09/16 14:13, Stuart Yoder wrote:
>>
>>
>>> -----Original Message-----
>>> From: Robin Murphy [mailto:robin.murphy at arm.com]
>>> Sent: Friday, September 23, 2016 7:17 AM
>>> To: Alison Wang <b18965@freescale.com>; shawnguo at kernel.org; kernel at pengutronix.de; Fabio Estevam
>>> Estevam <fabio.estevam@nxp.com>; linux at armlinux.org.uk; linux-arm-kernel at lists.infradead.org; linux-
>>> kernel at vger.kernel.org; Scott Wood <scott.wood@nxp.com>; Stuart Yoder <stuart.yoder@nxp.com>; Leo Li
>>> <leoyang.li@nxp.com>
>>> Cc: Jason Jin <jason.jin@nxp.com>
>>> Subject: Re: [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms
>>>
>>> Hi Alison,
>>>
>>> On 23/09/16 03:19, Alison Wang wrote:
>>>> The ARMv8 architecture supports:
>>>> 1. 64-bit execution state, AArch64.
>>>> 2. 32-bit execution state, AArch32, that is compatible with previous
>>>> versions of the ARM architecture.
>>>>
>>>> LayerScape platforms are compliant with ARMv8 architecture. This patch
>>>> is to support running 32-bit Linux kernel for LayerScape platforms.
>>>>
>>>> Verified on LayerScape LS1043ARDB, LS1012ARDB, LS1046ARDB boards.
>>>>
>>>> Signed-off-by: Ebony Zhu <ebony.zhu@nxp.com>
>>>> Signed-off-by: Alison Wang <alison.wang@nxp.com>
>>>> ---
>>>> arch/arm/Kconfig | 9 +++++++++
>>>> arch/arm/mach-imx/Kconfig | 14 ++++++++++++++
>>>> arch/arm/mach-imx/Makefile | 4 +++-
>>>> arch/arm/mach-imx/mach-layerscape.c | 23 +++++++++++++++++++++++
>>>> 4 files changed, 49 insertions(+), 1 deletion(-)
>>>> create mode 100644 arch/arm/mach-imx/mach-layerscape.c
>>>>
>>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>>> index f0c8068..e8d470e 100644
>>>> --- a/arch/arm/Kconfig
>>>> +++ b/arch/arm/Kconfig
>>>> @@ -294,6 +294,15 @@ config PGTABLE_LEVELS
>>>> default 3 if ARM_LPAE
>>>> default 2
>>>>
>>>> +config ARCH_AARCH32_ES_SUPPORT
>>>> + def_bool n
>>>> + help
>>>> + The ARMv8 architecture supports 64-bit execution state, AArch64
>>>> + and 32-bit execution state, AArch32, that is compatible with
>>>> + previous versions of the ARM architecture.
>>>> +
>>>> + Enable AArch32 execution state support for ARMv8 architecture.
>>>
>>> What's this supposed to do, exactly? I've been running 32-bit kernels on
>>> my Juno with very little issue (beyond a couple of DT tweaks, and some
>>> firmware hacks with a corresponding bit of A64 assembly tacked on the
>>> front of the zImage to switch into AArch32 state).
>>
>> Which arch/arm/mach-* platform are you using for Juno?
>
> I don't even know! :) I just start with a multi_v7_defconfig plus a few
> extra bits (LPAE, KVM, sil24, sky2, etc.) and it works. I guess it's the
> combination of mach-vexpress and mach-virt.
I believe the answer is none. Enabling VExpress may enable other
drivers, but obviously none of the code in mach-vexpress is needed
since it is not used for 64-bit builds.
Rob
^ permalink raw reply
* [PATCH 04/10] [v3] dt-bindings: qoriq-clock: update for more SoCs
From: Rob Herring @ 2016-09-23 13:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473754203-22970-5-git-send-email-shh.xie@gmail.com>
On Tue, Sep 13, 2016 at 04:09:57PM +0800, shh.xie at gmail.com wrote:
> From: Shaohui Xie <Shaohui.Xie@nxp.com>
>
> Adds compatible for SoCs which use clockgen, the SoCs are LS1043A,
> LS1046A, LS2080A.
>
> Signed-off-by: Shaohui Xie <Shaohui.Xie@nxp.com>
> ---
> change in v3:
> 1. new patch.
>
> Documentation/devicetree/bindings/clock/qoriq-clock.txt | 3 +++
> 1 file changed, 3 insertions(+)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 02/10][v3] dt-bindings: fsl: updates bindings for some SoC-specific devices
From: Rob Herring @ 2016-09-23 13:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473754203-22970-3-git-send-email-shh.xie@gmail.com>
On Tue, Sep 13, 2016 at 04:09:55PM +0800, shh.xie at gmail.com wrote:
> From: Shaohui Xie <Shaohui.Xie@nxp.com>
Again, subject could still be more specific. Aim to make it unique
enough that the same subject could never appear again.
> SCFG and DCFG are SoC-specific devices can be found on SoCs like LS1021A,
> LS1043A and LS1046A, this patch updates bindings for SCFG and DCFG to
> reflect more SoCs.
>
> Signed-off-by: Shaohui Xie <Shaohui.Xie@nxp.com>
> ---
> changes in V3:
> 1. added supported <chip>s.
>
> change in V2:
> 1. new patch.
>
> Documentation/devicetree/bindings/arm/fsl.txt | 14 +++++++++++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* [PATCH 01/10] [v3] dt-bindings: fsl: update for more SoCs
From: Rob Herring @ 2016-09-23 13:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1473754203-22970-2-git-send-email-shh.xie@gmail.com>
On Tue, Sep 13, 2016 at 04:09:54PM +0800, shh.xie at gmail.com wrote:
> From: Shaohui Xie <Shaohui.Xie@nxp.com>
The subject could be more specific: "Add LS1043A/LS1046A/LS2080A SoC
compatible strings"
>
> Adds SoC compatible for LS1043A and LS2080A which are supported, and
> for LS1046A which is going to be supported.
>
> Signed-off-by: Shaohui Xie <Shaohui.Xie@nxp.com>
> ---
> changes in V3:
> 1. new patch.
>
> Documentation/devicetree/bindings/arm/fsl.txt | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
Otherwise,
Acked-by: Rob Herring <robh@kernel.org>
Rob
^ permalink raw reply
* [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms
From: Robin Murphy @ 2016-09-23 13:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <VI1PR0401MB2638049F479731B3CC903B248DC80@VI1PR0401MB2638.eurprd04.prod.outlook.com>
On 23/09/16 14:13, Stuart Yoder wrote:
>
>
>> -----Original Message-----
>> From: Robin Murphy [mailto:robin.murphy at arm.com]
>> Sent: Friday, September 23, 2016 7:17 AM
>> To: Alison Wang <b18965@freescale.com>; shawnguo at kernel.org; kernel at pengutronix.de; Fabio Estevam
>> Estevam <fabio.estevam@nxp.com>; linux at armlinux.org.uk; linux-arm-kernel at lists.infradead.org; linux-
>> kernel at vger.kernel.org; Scott Wood <scott.wood@nxp.com>; Stuart Yoder <stuart.yoder@nxp.com>; Leo Li
>> <leoyang.li@nxp.com>
>> Cc: Jason Jin <jason.jin@nxp.com>
>> Subject: Re: [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms
>>
>> Hi Alison,
>>
>> On 23/09/16 03:19, Alison Wang wrote:
>>> The ARMv8 architecture supports:
>>> 1. 64-bit execution state, AArch64.
>>> 2. 32-bit execution state, AArch32, that is compatible with previous
>>> versions of the ARM architecture.
>>>
>>> LayerScape platforms are compliant with ARMv8 architecture. This patch
>>> is to support running 32-bit Linux kernel for LayerScape platforms.
>>>
>>> Verified on LayerScape LS1043ARDB, LS1012ARDB, LS1046ARDB boards.
>>>
>>> Signed-off-by: Ebony Zhu <ebony.zhu@nxp.com>
>>> Signed-off-by: Alison Wang <alison.wang@nxp.com>
>>> ---
>>> arch/arm/Kconfig | 9 +++++++++
>>> arch/arm/mach-imx/Kconfig | 14 ++++++++++++++
>>> arch/arm/mach-imx/Makefile | 4 +++-
>>> arch/arm/mach-imx/mach-layerscape.c | 23 +++++++++++++++++++++++
>>> 4 files changed, 49 insertions(+), 1 deletion(-)
>>> create mode 100644 arch/arm/mach-imx/mach-layerscape.c
>>>
>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>> index f0c8068..e8d470e 100644
>>> --- a/arch/arm/Kconfig
>>> +++ b/arch/arm/Kconfig
>>> @@ -294,6 +294,15 @@ config PGTABLE_LEVELS
>>> default 3 if ARM_LPAE
>>> default 2
>>>
>>> +config ARCH_AARCH32_ES_SUPPORT
>>> + def_bool n
>>> + help
>>> + The ARMv8 architecture supports 64-bit execution state, AArch64
>>> + and 32-bit execution state, AArch32, that is compatible with
>>> + previous versions of the ARM architecture.
>>> +
>>> + Enable AArch32 execution state support for ARMv8 architecture.
>>
>> What's this supposed to do, exactly? I've been running 32-bit kernels on
>> my Juno with very little issue (beyond a couple of DT tweaks, and some
>> firmware hacks with a corresponding bit of A64 assembly tacked on the
>> front of the zImage to switch into AArch32 state).
>
> Which arch/arm/mach-* platform are you using for Juno?
I don't even know! :) I just start with a multi_v7_defconfig plus a few
extra bits (LPAE, KVM, sil24, sky2, etc.) and it works. I guess it's the
combination of mach-vexpress and mach-virt.
Robin.
>
> Thanks,
> Stuart
>
^ permalink raw reply
* [PATCH v6 3/4] arm64: arch_timer: Work around QorIQ Erratum A-008585
From: Marc Zyngier @ 2016-09-23 13:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474533318-7796-3-git-send-email-oss@buserror.net>
On 22/09/16 09:35, Scott Wood wrote:
> Erratum A-008585 says that the ARM generic timer counter "has the
> potential to contain an erroneous value for a small number of core
> clock cycles every time the timer value changes". Accesses to TVAL
> (both read and write) are also affected due to the implicit counter
> read. Accesses to CVAL are not affected.
>
> The workaround is to reread TVAL and count registers until successive
> reads return the same value. Writes to TVAL are replaced with an
> equivalent write to CVAL.
>
> The workaround is to reread TVAL and count registers until successive reads
> return the same value, and when writing TVAL to retry until counter
> reads before and after the write return the same value.
>
> The workaround is enabled if the fsl,erratum-a008585 property is found in
> the timer node in the device tree. This can be overridden with the
> clocksource.arm_arch_timer.fsl-a008585 boot parameter, which allows KVM
> users to enable the workaround until a mechanism is implemented to
> automatically communicate this information.
>
> This erratum can be found on LS1043A and LS2080A.
>
> Signed-off-by: Scott Wood <oss@buserror.net>
> ---
> v6:
> - Addressed feedback from Mark Rutland
>
> v5:
> - Export arch_timer_read_ool_enabled so that get_cycles() can be called
> from modules.
>
> v4:
> - Undef ARCH_TIMER_REG_READ after use
>
> v3:
> - Used cval rather than a loop for the write side of the erratum
> - Added a Kconfig control
> - Moved the device tree binding into its own patch
> - Added erratum to silicon-errata.txt
> - Changed function names to contain the erratum name
> - Factored out the setting of erratum versions of set_next_event
> to improve readability
> - Added a comment clarifying that the timeout is arbitrary
>
> v2:
> Significant rework based on feedback, including using static_key,
> disabling VDSO counter access rather than adding the workaround to the
> VDSO, and uninlining the loops.
>
> Dropped the separate property for indicating that writes to TVAL are
> affected, as I believe that's just a side effect of the implicit
> counter read being corrupted, and thus a chip that is affected by one
> will always be affected by the other.
>
> Dropped the arm32 portion as it seems there was confusion about whether
> LS1021A is affected. Currently I am being told that it is not
> affected.
>
> I considered writing to CVAL rather than looping on TVAL writes, but
> that would still have required separate set_next_event() code for the
> erratum, and adding CVAL to the enum would have required a bunch of
> extra handlers in switch statements (even where unused, due to compiler
> warnings about unhandled enum values) including in an arm32 header. It
> seemed better to avoid the arm32 interaction and new untested
> accessors.
>
> Signed-off-by: Scott Wood <oss@buserror.net>
> ---
> Documentation/arm64/silicon-errata.txt | 2 +
> Documentation/kernel-parameters.txt | 9 +++
> arch/arm64/include/asm/arch_timer.h | 47 ++++++++++++++-
> drivers/clocksource/Kconfig | 10 ++++
> drivers/clocksource/arm_arch_timer.c | 104 +++++++++++++++++++++++++++++++++
> 5 files changed, 169 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/arm64/silicon-errata.txt b/Documentation/arm64/silicon-errata.txt
> index 4da60b4..041e3a9 100644
> --- a/Documentation/arm64/silicon-errata.txt
> +++ b/Documentation/arm64/silicon-errata.txt
> @@ -60,3 +60,5 @@ stable kernels.
> | Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 |
> | Cavium | ThunderX Core | #27456 | CAVIUM_ERRATUM_27456 |
> | Cavium | ThunderX SMMUv2 | #27704 | N/A |
> +| | | | |
> +| Freescale/NXP | LS2080A/LS1043A | A-008585 | FSL_ERRATUM_A008585 |
> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
> index 46c030a..fb4de4d 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -698,6 +698,15 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
> loops can be debugged more effectively on production
> systems.
>
> + clocksource.arm_arch_timer.fsl-a008585=
> + [ARM64]
> + Format: <bool>
> + Enable/disable the workaround of Freescale/NXP
> + erratum A-008585. This can be useful for KVM
> + guests, if the guest device tree doesn't show the
> + erratum. If unspecified, the workaround is
> + enabled based on the device tree.
> +
> clearcpuid=BITNUM [X86]
> Disable CPUID feature X for the kernel. See
> arch/x86/include/asm/cpufeatures.h for the valid bit
> diff --git a/arch/arm64/include/asm/arch_timer.h b/arch/arm64/include/asm/arch_timer.h
> index 7ff386c..cddd5b7 100644
> --- a/arch/arm64/include/asm/arch_timer.h
> +++ b/arch/arm64/include/asm/arch_timer.h
> @@ -24,10 +24,51 @@
>
> #include <linux/bug.h>
> #include <linux/init.h>
> +#include <linux/jump_label.h>
> #include <linux/types.h>
>
> #include <clocksource/arm_arch_timer.h>
>
> +#if IS_ENABLED(CONFIG_FSL_ERRATUM_A008585)
> +extern struct static_key_false arch_timer_read_ool_enabled;
> +#define needs_fsl_a008585_workaround() \
> + static_branch_unlikely(&arch_timer_read_ool_enabled)
> +#else
> +#define needs_fsl_a008585_workaround() false
> +#endif
> +
> +u32 __fsl_a008585_read_cntp_tval_el0(void);
> +u32 __fsl_a008585_read_cntv_tval_el0(void);
> +u64 __fsl_a008585_read_cntvct_el0(void);
> +
> +/*
> + * The number of retries is an arbitrary value well beyond the highest number
> + * of iterations the loop has been observed to take.
> + */
> +#define __fsl_a008585_read_reg(reg) ({ \
> + u64 _old, _new; \
> + int _retries = 200; \
> + \
> + do { \
> + _old = read_sysreg(reg); \
> + _new = read_sysreg(reg); \
> + _retries--; \
> + } while (unlikely(_old != _new) && _retries); \
> + \
> + WARN_ON_ONCE(!_retries); \
> + _new; \
> +})
> +
> +#define arch_timer_unstable_reg_read(reg) \
I think this name is the only thing I don't like about this patch,
because it is only unstable if the workaround is on. This is a minor
thing and it can be addressed when/after merging it. No need to respin
it on this account.
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
The usual question is "Who takes it?". I'm quite keen on it, as my
LS2085 is otherwise completely unusable.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] drm/sun4i: rgb: Enable panel after controller
From: Maxime Ripard @ 2016-09-23 13:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANwerB2pmO7AMqmE9SMR1vFFsY5jMUALGSvtd=AvpU1=_jSHUw@mail.gmail.com>
On Thu, Sep 22, 2016 at 08:03:31AM +1000, Jonathan Liu wrote:
> Hi Maxime,
>
> On Thursday, 22 September 2016, Maxime Ripard <maxime.ripard@free-electrons.
> com> wrote:
>
> > On Wed, Sep 21, 2016 at 11:03:04PM +1000, Jonathan Liu wrote:
> > > The panel should be enabled after the controller so that the panel
> > > prepare/enable delays are properly taken into account. Similarly, the
> > > panel should be disabled before the controller so that the panel
> > > unprepare/disable delays are properly taken into account.
> > >
> > > This is useful for avoiding visual glitches.
> >
> > This is not really taking any delays into account, especially since
> > drm_panel_enable and prepare are suppose to block until their
> > operation is complete.
>
>
> drm_panel_prepare turns on power to the LCD using enable-gpios property of
> the panel and then blocks for prepare delay. The prepare delay for panel
> can be set to how long it takes between the time the panel is powered to
> when it is ready to receive images. If backlight property is specified the
> backlight will be off while the panel is powered on.
>
> drm_panel_enable blocks for enable delay and then turns on the backlight.
> The enable delay can be set to how long it takes for panel to start making
> the image visible after receiving the first valid frame. For example if the
> panel starts off as white and the TFT takes some time to initialize to
> black before it shows the image being received.
>
> Refer to drivers/gpu/drm/panel-panel.simple.c for details.
>From drm_panel.h:
"""
* drm_panel_enable - enable a panel
* @panel: DRM panel
*
* Calling this function will cause the panel display drivers to be turned on
* and the backlight to be enabled. Content will be visible on screen after
* this call completes.
"""
"""
* drm_panel_prepare - power on a panel
* @panel: DRM panel
*
* Calling this function will enable power and deassert any reset signals to
* the panel. After this has completed it is possible to communicate with any
* integrated circuitry via a command bus.
"""
Those comments clearly says that the caller should not have to deal
with the delays, even more so by just moving calls around and hoping
that the code running in between is adding enough delay for the panel
to behave properly.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160923/1be13bd7/attachment.sig>
^ permalink raw reply
* [PATCH 2/3] gpio: Add a driver for the Raspberry Pi's firmware GPIO calls.
From: Eric Anholt @ 2016-09-23 13:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkda6HpJp97FUAh6yvo-BhiDbAXxzQS9U6uT+jvg6hiB8ag@mail.gmail.com>
Linus Walleij <linus.walleij@linaro.org> writes:
> On Mon, Sep 19, 2016 at 6:13 PM, Eric Anholt <eric@anholt.net> wrote:
>
>> This driver will be used for accessing the FXL6408 GPIO exander on the
>> Pi3. We can't drive it directly from Linux because the firmware is
>> continuously polling one of the expander's lines to do its
>> undervoltage detection.
>>
>> Signed-off-by: Eric Anholt <eric@anholt.net>
> (...)
>
>> +config GPIO_RASPBERRYPI
>> + tristate "Raspberry Pi firmware-based GPIO access"
>> + depends on OF_GPIO && RASPBERRYPI_FIRMWARE && (ARCH_BCM2835 || COMPILE_TEST)
>> + help
>> + Turns on support for using the Raspberry Pi firmware to
>> + control GPIO pins. Used for access to the FXL6408 GPIO
>> + expander on the Pi 3.
>
> Maybe it should be named GPIO_RPI_FXL6408 ?
>
> (No strong opinion.)
See DT binding comment -- I think since this driver has no dependency on
being to the 6408 on the pi3, we shouldn't needlessly bind it to the
FXL6408. (the help comment was just context for why you would want the
driver today).
>> +static int rpi_gpio_dir_in(struct gpio_chip *gc, unsigned off)
>> +{
>> + /* We don't have direction control. */
>> + return -EINVAL;
>> +}
>> +
>> +static int rpi_gpio_dir_out(struct gpio_chip *gc, unsigned off, int val)
>> +{
>> + /* We don't have direction control. */
>> + return -EINVAL;
>> +}
>
> IMO this should return OK if you try to set it to the direction
> that the line is hardwired for in that case, not just fail everything.
>
> If you return errors here, any generic driver that tries to
> set the line as input or output will fail and then require a
> second workaround in that driver if it is used on rpi etc etc.
>
> Try to return zero if the consumer asks for the direction that
> the line is set to.
>
> Also implement .get_direction(). Doing so will show how to
> do the above two calls in the right way.
I was worried about the lack of direction support. The firmware
interface doesn't give me anything for direction, and a get or set
of the value doesn't try to set direction.
I can try to bother them to give me support for that, but if they
cooperate on that it means that users will only get HDMI detection once
they update firmware.
The alternative to new firmware interface would be to provide a bunch of
DT saying which of these should be in/out at boot time and refuse to
change them after that. That seems like a mess, though.
>> +static void rpi_gpio_set(struct gpio_chip *gc, unsigned off, int val)
>> +{
>> + struct rpi_gpio *rpi = container_of(gc, struct rpi_gpio, gc);
>> + u32 packet[2] = { rpi->offset + off, val };
>> + int ret;
>> +
>> + ret = rpi_firmware_property(rpi->firmware,
>> + RPI_FIRMWARE_SET_GPIO_STATE,
>> + &packet, sizeof(packet));
>> + if (ret)
>> + dev_err(rpi->dev, "Error setting GPIO %d state: %d\n", off, ret);
>> +}
>> +
>> +static int rpi_gpio_get(struct gpio_chip *gc, unsigned off)
>> +{
>> + struct rpi_gpio *rpi = container_of(gc, struct rpi_gpio, gc);
>> + u32 packet[2] = { rpi->offset + off, 0 };
>> + int ret;
>> +
>> + ret = rpi_firmware_property(rpi->firmware,
>> + RPI_FIRMWARE_GET_GPIO_STATE,
>> + &packet, sizeof(packet));
>> + if (ret) {
>> + dev_err(rpi->dev, "Error getting GPIO state: %d\n", ret);
>> + return ret;
>> + } else if (packet[0]) {
>> + dev_err(rpi->dev, "Firmware error getting GPIO state: %d\n",
>> + packet[0]);
>> + return -EINVAL;
>> + } else {
>> + return packet[1];
>> + }
>
> You can just remove the last } else { } clause and return on a
> single line.
>
> Please do it like this though:
>
> return !!packet[1];
>
> So you clamp the returned value to a boolean.
Will do.
>> + rpi->gc.get = rpi_gpio_get;
>> + rpi->gc.set = rpi_gpio_set;
>> + rpi->gc.can_sleep = true;
>> +
>> + ret = gpiochip_add(&rpi->gc);
>> + if (ret)
>> + return ret;
>
> Use devm_gpiochip_add_data() and pass NULL as data
> so you can still use the devm* function.
Oh, nice.
>> diff --git a/include/soc/bcm2835/raspberrypi-firmware.h b/include/soc/bcm2835/raspberrypi-firmware.h
>> index 3fb357193f09..671ccd00aea2 100644
>> --- a/include/soc/bcm2835/raspberrypi-firmware.h
>> +++ b/include/soc/bcm2835/raspberrypi-firmware.h
>> @@ -73,11 +73,13 @@ enum rpi_firmware_property_tag {
>> RPI_FIRMWARE_GET_DISPMANX_RESOURCE_MEM_HANDLE = 0x00030014,
>> RPI_FIRMWARE_GET_EDID_BLOCK = 0x00030020,
>> RPI_FIRMWARE_GET_DOMAIN_STATE = 0x00030030,
>> + RPI_FIRMWARE_GET_GPIO_STATE = 0x00030041,
>> RPI_FIRMWARE_SET_CLOCK_STATE = 0x00038001,
>> RPI_FIRMWARE_SET_CLOCK_RATE = 0x00038002,
>> RPI_FIRMWARE_SET_VOLTAGE = 0x00038003,
>> RPI_FIRMWARE_SET_TURBO = 0x00038009,
>> RPI_FIRMWARE_SET_DOMAIN_STATE = 0x00038030,
>> + RPI_FIRMWARE_SET_GPIO_STATE = 0x00038041,
>
> Can you please merge this orthogonally into the rpi tree to ARM SoC?
This driver would appear in the rpi downstream tree once we settle the
driver here. Or are you asking me to delay this series until I can get
them to pull just a patch extending the set of packets?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20160923/83848ae6/attachment.sig>
^ permalink raw reply
* [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms
From: Stuart Yoder @ 2016-09-23 13:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f4195baa-907d-2c00-eb62-d4452ed749c8@arm.com>
> -----Original Message-----
> From: Robin Murphy [mailto:robin.murphy at arm.com]
> Sent: Friday, September 23, 2016 7:17 AM
> To: Alison Wang <b18965@freescale.com>; shawnguo at kernel.org; kernel at pengutronix.de; Fabio Estevam
> Estevam <fabio.estevam@nxp.com>; linux at armlinux.org.uk; linux-arm-kernel at lists.infradead.org; linux-
> kernel at vger.kernel.org; Scott Wood <scott.wood@nxp.com>; Stuart Yoder <stuart.yoder@nxp.com>; Leo Li
> <leoyang.li@nxp.com>
> Cc: Jason Jin <jason.jin@nxp.com>
> Subject: Re: [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms
>
> Hi Alison,
>
> On 23/09/16 03:19, Alison Wang wrote:
> > The ARMv8 architecture supports:
> > 1. 64-bit execution state, AArch64.
> > 2. 32-bit execution state, AArch32, that is compatible with previous
> > versions of the ARM architecture.
> >
> > LayerScape platforms are compliant with ARMv8 architecture. This patch
> > is to support running 32-bit Linux kernel for LayerScape platforms.
> >
> > Verified on LayerScape LS1043ARDB, LS1012ARDB, LS1046ARDB boards.
> >
> > Signed-off-by: Ebony Zhu <ebony.zhu@nxp.com>
> > Signed-off-by: Alison Wang <alison.wang@nxp.com>
> > ---
> > arch/arm/Kconfig | 9 +++++++++
> > arch/arm/mach-imx/Kconfig | 14 ++++++++++++++
> > arch/arm/mach-imx/Makefile | 4 +++-
> > arch/arm/mach-imx/mach-layerscape.c | 23 +++++++++++++++++++++++
> > 4 files changed, 49 insertions(+), 1 deletion(-)
> > create mode 100644 arch/arm/mach-imx/mach-layerscape.c
> >
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index f0c8068..e8d470e 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -294,6 +294,15 @@ config PGTABLE_LEVELS
> > default 3 if ARM_LPAE
> > default 2
> >
> > +config ARCH_AARCH32_ES_SUPPORT
> > + def_bool n
> > + help
> > + The ARMv8 architecture supports 64-bit execution state, AArch64
> > + and 32-bit execution state, AArch32, that is compatible with
> > + previous versions of the ARM architecture.
> > +
> > + Enable AArch32 execution state support for ARMv8 architecture.
>
> What's this supposed to do, exactly? I've been running 32-bit kernels on
> my Juno with very little issue (beyond a couple of DT tweaks, and some
> firmware hacks with a corresponding bit of A64 assembly tacked on the
> front of the zImage to switch into AArch32 state).
Which arch/arm/mach-* platform are you using for Juno?
Thanks,
Stuart
^ permalink raw reply
* [PATCH] iommu/arm-smmu: Work around ARM DMA configuration
From: Robin Murphy @ 2016-09-23 13:11 UTC (permalink / raw)
To: linux-arm-kernel
The 32-bit ARM DMA configuration code predates the IOMMU core's default
domain functionality, and instead relies on allocating its own domains
and attaching any devices using the generic IOMMU binding to them.
Unfortunately, it does this relatively early on in the creation of the
device, before we've seen our add_device callback, which leads us to
attempt to operate on a half-configured master.
To avoid a crash, check for this situation on attach, but refuse to
play, as there's nothing we can do. This at least allows VFIO to keep
working for people who update their 32-bit DTs to the generic binding,
albeit with a few (innocuous) warnings from the DMA layer on boot.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
---
drivers/iommu/arm-smmu.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index c841eb7a1a74..3af7f8f62d0a 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1228,6 +1228,16 @@ static int arm_smmu_attach_dev(struct iommu_domain *domain, struct device *dev)
return -ENXIO;
}
+ /*
+ * FIXME: The arch/arm DMA API code tries to attach devices to its own
+ * domains between of_xlate() and add_device() - we have no way to cope
+ * with that, so until ARM gets converted to rely on groups and default
+ * domains, just say no (but more politely than by dereferencing NULL).
+ * This should be at least a WARN_ON once that's sorted.
+ */
+ if (!fwspec->iommu_priv)
+ return -ENODEV;
+
smmu = fwspec_smmu(fwspec);
/* Ensure that the domain is finalised */
ret = arm_smmu_init_domain_context(domain, smmu);
--
2.8.1.dirty
^ permalink raw reply related
* [PATCH 2/2] drivers: cci: add missing CCI port availability firmware check
From: Lorenzo Pieralisi @ 2016-09-23 13:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923130907.4187-1-lorenzo.pieralisi@arm.com>
The CCI ports programming interface is available to the kernel
only when booted in secure mode (or when firmware enables
non-secure access to override CCI ports control). In both cases,
firmware reports the CCI ports availability through the device
tree CCI ports nodes, which must be parsed and their status checked
by the kernel probing path.
This check is currently missing and may cause the kernel to
erroneously believe it is free to take control of CCI ports
where in practice CCI ports control is forbidden.
Add the missing CCI port availability check to the CCI driver
in order to guarantee sane CCI usage.
Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Liviu Dudau <liviu.dudau@arm.com>
Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
---
drivers/bus/arm-cci.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
index 5755907f..3c7a1c7 100644
--- a/drivers/bus/arm-cci.c
+++ b/drivers/bus/arm-cci.c
@@ -2199,6 +2199,9 @@ static int cci_probe_ports(struct device_node *np)
if (!of_match_node(arm_cci_ctrl_if_matches, cp))
continue;
+ if (!of_device_is_available(cp))
+ continue;
+
i = nb_ace + nb_ace_lite;
if (i >= nb_cci_ports)
@@ -2241,6 +2244,13 @@ static int cci_probe_ports(struct device_node *np)
ports[i].dn = cp;
}
+ /*
+ * If there is no CCI port that is under kernel control
+ * return early and report probe status.
+ */
+ if (!nb_ace && !nb_ace_lite)
+ return -ENODEV;
+
/* initialize a stashed array of ACE ports to speed-up look-up */
cci_ace_init_ports();
--
2.10.0
^ permalink raw reply related
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