* [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 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 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 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 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 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] 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/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 v2 2/3] musb: sunxi: Remove custom babble handling
From: Bin Liu @ 2016-09-23 13:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <db52a0d4-74f1-4f47-eb67-bcfbd66f174f@redhat.com>
On Fri, Sep 23, 2016 at 04:42:26PM +0300, Hans de Goede wrote:
> 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.
Thanks.
If Kishon gives his Acked-by, I will take all the 3 patches. Or
I can just take the 2 musb patches into my tree.
Regards,
-Bin.
^ permalink raw reply
* [PATCH 1/3] dt-bindings: Add a binding for the RPi firmware GPIO driver.
From: Linus Walleij @ 2016-09-23 13:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87ponu931e.fsf@eliezer.anholt.net>
On Fri, Sep 23, 2016 at 3:08 PM, Eric Anholt <eric@anholt.net> wrote:
> Sort of related: I also worry that we have races with the firmware for
> the platform GPIO bits, since both ARM and firmware are doing RMWs (or,
> even worse, maybe just Ws?) of the registers controlled by the pinctrl
> driver. Hopefully I can get the firmware to pass control of devices
> like this over to Linux, with firmware making requests to us, but I
> don't know if that will happen and we may need to access other GPIOs
> using this interface :(
For the race with firmware I have no good solutions, it's just one of
those things I guess :(
When two kernel drivers compete about registers, say for example
one driver needs to RMW bits 0-5 and another driver needs to
RMW bits 7-11, the right solution is usually to use syscon
and then regmap-mmio will deal with the concurrency as part
of regmap_update_bits() etc.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms
From: Stuart Yoder @ 2016-09-23 14:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c6697a9c-013b-9880-e52f-8de2f0a5b7ae@arm.com>
> -----Original Message-----
> From: Robin Murphy [mailto:robin.murphy at arm.com]
> Sent: Friday, September 23, 2016 8:19 AM
> To: Stuart Yoder <stuart.yoder@nxp.com>; 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>; 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
>
> 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.
Thanks. A question about the switch into aarch32 state... our assumption
was that the kernel starts at EL2. In this proof of concept we're doing the
switch to aarch32/EL2 in firmware. And what I'm being told is that the
firmware aarch64 EL2 code cannot switch to aarch32 EL2 without some
assistance from EL3 firmware. This is leading us to invent a new
SMC call to do this.
Did you face this?
If there is such a requirement, it's something begging for standardization.
Doesn't make sense for multiple divergent approaches for switching from
aarch64/EL2 to aarch32/EL2.
Thanks,
Stuart
^ permalink raw reply
* [1/2] pwm: sunxi: allow the pwm to finish its pulse before disable
From: Jonathan Liu @ 2016-09-23 14:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1472147411-30424-2-git-send-email-oliver@schinagl.nl>
On 26 August 2016 at 03:50, <oliver@schinagl.nl> wrote:
> When we inform the PWM block to stop toggeling the output, we may end up
> in a state where the output is not what we would expect (e.g. not the
> low-pulse) but whatever the output was at when the clock got disabled.
>
> To counter this we have to wait for maximally the time of one whole
> period to ensure the pwm hardware was able to finish. Since we already
> told the PWM hardware to disable it self, it will not continue toggling
> but merly finish its current pulse.
>
> If a whole period is considered to much, it may be contemplated to use a
> half period + a little bit to ensure we get passed the transition.
>
> Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
> ---
> drivers/pwm/pwm-sun4i.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
> index 03a99a5..5e97c8a 100644
> --- a/drivers/pwm/pwm-sun4i.c
> +++ b/drivers/pwm/pwm-sun4i.c
> @@ -8,6 +8,7 @@
>
> #include <linux/bitops.h>
> #include <linux/clk.h>
> +#include <linux/delay.h>
> #include <linux/err.h>
> #include <linux/io.h>
> #include <linux/module.h>
> @@ -245,6 +246,16 @@ static void sun4i_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
> spin_lock(&sun4i_pwm->ctrl_lock);
> val = sun4i_pwm_readl(sun4i_pwm, PWM_CTRL_REG);
> val &= ~BIT_CH(PWM_EN, pwm->hwpwm);
> + sun4i_pwm_writel(sun4i_pwm, val, PWM_CTRL_REG);
> + spin_unlock(&sun4i_pwm->ctrl_lock);
> +
> + /* Allow for the PWM hardware to finish its last toggle. The pulse
> + * may have just started and thus we should wait a full period.
> + */
> + ndelay(pwm_get_period(pwm));
> +
> + spin_lock(&sun4i_pwm->ctrl_lock);
> + val = sun4i_pwm_readl(sun4i_pwm, PWM_CTRL_REG);
> val &= ~BIT_CH(PWM_CLK_GATING, pwm->hwpwm);
> sun4i_pwm_writel(sun4i_pwm, val, PWM_CTRL_REG);
> spin_unlock(&sun4i_pwm->ctrl_lock);
I had some issues where setting the brightness for pwm-backlight to 0
was not turning off the backlight sometimes.
This patch fixes the issue for me. Thanks.
Tested-by: Jonathan Liu <net147@gmail.com>
^ permalink raw reply
* [PATCH 1/2] ARM: vexpress: refine MCPM smp operations override criteria
From: Lorenzo Pieralisi @ 2016-09-23 14:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160923130907.4187-1-lorenzo.pieralisi@arm.com>
On Fri, Sep 23, 2016 at 02:09:06PM +0100, Lorenzo Pieralisi wrote:
> Current vexpress smp init code detects whether to override the
> default smp ops with MCPM smp ops by matching the "cci-400"
> compatible string, in that MCPM requires control over CCI ports
> to manage low-power states entry/exit.
>
> The "cci-400" compatible string check is a necessary but not
> sufficient condition for MCPM to work, because the cci-400
> can be made visible to the kernel, but firmware can nonetheless
> disable non-secure CCI ports control, while still allowing PMU
> access; if booted in non-secure world, the kernel would still
> blindly override smp operations with MCPM operations, resulting
> in kernel faults when the CCI ports programming interface is
> accessed from non-secure world.
>
> This means that the "cci-400" compatible string check would
> result in a false positive in systems that eg boot in HYP mode,
> where CCI ports non-secure access is explicitly not allowed,
> and it is reported in the respective device tree nodes with
> CCI ports marked as disabled.
>
> Refactor the smp operations initialization to make sure that
> the kernel is actually allowed to take control over CCI ports
> (by enabling MCPM smp operations) before overriding default
> vexpress smp operations.
>
> 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: Marc Zyngier <marc.zyngier@arm.com>
> ---
> arch/arm/mach-vexpress/platsmp.c | 31 ++++++++++++++++++++++++-------
> 1 file changed, 24 insertions(+), 7 deletions(-)
>
> diff --git a/arch/arm/mach-vexpress/platsmp.c b/arch/arm/mach-vexpress/platsmp.c
> index 8b8d072..6cfd782 100644
> --- a/arch/arm/mach-vexpress/platsmp.c
> +++ b/arch/arm/mach-vexpress/platsmp.c
> @@ -26,17 +26,34 @@
> bool __init vexpress_smp_init_ops(void)
> {
> #ifdef CONFIG_MCPM
> + int cpu;
> + struct device_node *cpu_node, *cci_node;
> +
> /*
> - * The best way to detect a multi-cluster configuration at the moment
> - * is to look for the presence of a CCI in the system.
> + * The best way to detect a multi-cluster configuration
> + * is to detect if the kernel can take over CCI ports
> + * control. Loop over possible CPUs and check if CCI
> + * port control is available.
> * Override the default vexpress_smp_ops if so.
> */
> - struct device_node *node;
> - node = of_find_compatible_node(NULL, NULL, "arm,cci-400");
> - if (node && of_device_is_available(node)) {
> - mcpm_smp_set_ops();
> - return true;
> + for_each_possible_cpu(cpu) {
> + bool available;
> +
> + cpu_node = of_get_cpu_node(cpu, NULL);
> + if (WARN(!cpu_node, "Missing cpu device node!"))
> + return false;
> +
> + cci_node = of_parse_phandle(cpu_node, "cci-control-port", 0);
> + available = cci_node && of_device_is_available(cci_node);
> + of_node_put(cci_node);
> + of_node_put(cpu_node);
> +
> + if (!available)
> + return false;
> }
> +
> + mcpm_smp_set_ops();
> + return true;
> #endif
> return false;
For the records, while moving the code around I missed I was ending
up with this idiotic double return, I have already reworked the patch
and will squash changes in the final version if we agree on the bulk of
the code.
Lorenzo
^ permalink raw reply
* [1/2] pwm: sunxi: allow the pwm to finish its pulse before disable
From: Olliver Schinagl @ 2016-09-23 14:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANwerB2LwWShNEUmNNbuH_4GY90gSpVmrxbC+oLK4p51cxUe2g@mail.gmail.com>
Hey Jonathan,
On 23-09-16 16:02, Jonathan Liu wrote:
> On 26 August 2016 at 03:50, <oliver@schinagl.nl> wrote:
>> When we inform the PWM block to stop toggeling the output, we may end up
>> in a state where the output is not what we would expect (e.g. not the
>> low-pulse) but whatever the output was at when the clock got disabled.
>>
>> To counter this we have to wait for maximally the time of one whole
>> period to ensure the pwm hardware was able to finish. Since we already
>> told the PWM hardware to disable it self, it will not continue toggling
>> but merly finish its current pulse.
>>
>> If a whole period is considered to much, it may be contemplated to use a
>> half period + a little bit to ensure we get passed the transition.
>>
>> Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
>> ---
>> drivers/pwm/pwm-sun4i.c | 11 +++++++++++
>> 1 file changed, 11 insertions(+)
>>
>> diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
>> index 03a99a5..5e97c8a 100644
>> --- a/drivers/pwm/pwm-sun4i.c
>> +++ b/drivers/pwm/pwm-sun4i.c
>> @@ -8,6 +8,7 @@
>>
>> #include <linux/bitops.h>
>> #include <linux/clk.h>
>> +#include <linux/delay.h>
>> #include <linux/err.h>
>> #include <linux/io.h>
>> #include <linux/module.h>
>> @@ -245,6 +246,16 @@ static void sun4i_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
>> spin_lock(&sun4i_pwm->ctrl_lock);
>> val = sun4i_pwm_readl(sun4i_pwm, PWM_CTRL_REG);
>> val &= ~BIT_CH(PWM_EN, pwm->hwpwm);
>> + sun4i_pwm_writel(sun4i_pwm, val, PWM_CTRL_REG);
>> + spin_unlock(&sun4i_pwm->ctrl_lock);
>> +
>> + /* Allow for the PWM hardware to finish its last toggle. The pulse
>> + * may have just started and thus we should wait a full period.
>> + */
>> + ndelay(pwm_get_period(pwm));
>> +
>> + spin_lock(&sun4i_pwm->ctrl_lock);
>> + val = sun4i_pwm_readl(sun4i_pwm, PWM_CTRL_REG);
>> val &= ~BIT_CH(PWM_CLK_GATING, pwm->hwpwm);
>> sun4i_pwm_writel(sun4i_pwm, val, PWM_CTRL_REG);
>> spin_unlock(&sun4i_pwm->ctrl_lock);
> I had some issues where setting the brightness for pwm-backlight to 0
> was not turning off the backlight sometimes.
> This patch fixes the issue for me. Thanks.
You are welcome, but there's some work still being done in this regard,
or rather, i have to find time to grab a scope and properly check the
output. So expect the proper fix to be coming to a kernel near you soon :)
Meanwhile, it seems to still confirm that this is needed. Thanks on that.
Olliver
>
> Tested-by: Jonathan Liu <net147@gmail.com>
^ permalink raw reply
* [PATCH 2/2] drm/rockchip: analogix_dp: Refuse to enable PSR if panel doesn't support it
From: Tomeu Vizoso @ 2016-09-23 14:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474639600-30090-1-git-send-email-tomeu.vizoso@collabora.com>
There's no point in enabling PSR when the panel doesn't support it.
This also avoids a problem when PSR gets enabled when a CRTC is being
disabled, because sometimes in that situation the DSP_HOLD_VALID_INTR
interrupt on which we wait will never arrive. This was observed on
RK3288 with a panel without PSR (veyron-jaq Chromebook).
It's very easy to reproduce by running the kms_rmfb test in IGT a few
times.
Signed-off-by: Tomeu Vizoso <tomeu.vizoso@collabora.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: Yakir Yang <ykk@rock-chips.com>
Cc: Archit Taneja <architt@codeaurora.org>
---
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index e83be157cc2a..8548e8271639 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -85,6 +85,9 @@ static void analogix_dp_psr_set(struct drm_encoder *encoder, bool enabled)
struct rockchip_dp_device *dp = to_dp(encoder);
unsigned long flags;
+ if (!analogix_dp_psr_supported(dp->dev))
+ return;
+
dev_dbg(dp->dev, "%s PSR...\n", enabled ? "Entry" : "Exit");
spin_lock_irqsave(&dp->psr_lock, flags);
--
2.7.4
^ permalink raw reply related
* [PATCH 2/3] gpio: Add a driver for the Raspberry Pi's firmware GPIO calls.
From: Linus Walleij @ 2016-09-23 14:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87mviy92qw.fsf@eliezer.anholt.net>
On Fri, Sep 23, 2016 at 3:15 PM, Eric Anholt <eric@anholt.net> wrote:
> Linus Walleij <linus.walleij@linaro.org> writes:
>> 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).
OK
>>> +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.
It has to be resolved one way or another I'm afraid.
Do you have an API in place to ask for the firmware version?
RPI_FIRMWARE_GET_FIRMWARE_REVISION seems to
exist at least?
In that case try to make some compromise, e.g. if lines 0 and 1
are output and the rest input in a certain firmware version:
struct rpi_gpio {
(...)
u8 dirs;
};
if (fw_version <= a)
rpi->dirs = 0x03;
else if (fw_version > a && fw_version <= b)
rpi->dirs = 0x07;
else
/* Ask firmware */
Then in e.g.
static int rpi_gpio_dir_in(struct gpio_chip *gc, unsigned off)
{
struct rpi_gpio *rpi = gpiochip_get_data(gc);
if (!(rpi->dirs & BIT(off)))
return 0;
return -EINVAL;
}
I think this should be managed by code in the driver like this
and not by any DT properties. I suspect also the ngpio number
is better to determine from looking at the fw version number.
>> Use devm_gpiochip_add_data() and pass NULL as data
>> so you can still use the devm* function.
>
> Oh, nice.
I forgot this: with devm_gpiochip_add_data() pass struct rpi_gpio *
as data then you can just:
static void rpi_gpio_set(struct gpio_chip *gc, unsigned off, int val)
{
- struct rpi_gpio *rpi = container_of(gc, struct rpi_gpio, gc);
+ struct rpi_gpio *rpi = gpiochip_get_data(gc);
Applies everywhere.
>>> 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?
Sorry I am not familiar with your development model. I don't know
about any RPI downstream tree... What I mean is that the patch to
include/soc/bcm2835/raspberrypi-firmware.h should be merged by
whoever is maintaining that file, it is not a GPIO file.
If I get an ACK from the maintainer I can take it into the GPIO
tree.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH v18 6/6] ARM: socfpga: fpga bridge driver support
From: Steffen Trumtrar @ 2016-09-23 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160712193645.9098-7-atull@opensource.altera.com>
Hi!
Alan Tull writes:
> Supports Altera SOCFPGA bridges:
> * fpga2sdram
> * fpga2hps
> * hps2fpga
> * lwhps2fpga
>
> Allows enabling/disabling the bridges through the FPGA
> Bridge Framework API functions.
>
> The fpga2sdram driver only supports enabling and disabling
> of the ports that been configured early on. This is due to
> a hardware limitation where the read, write, and command
> ports on the fpga2sdram bridge can only be reconfigured
> while there are no transactions to the sdram, i.e. when
> running out of OCRAM before the kernel boots.
>
> Device tree property 'init-val' configures the driver to
> enable or disable the bridge during probe. If the property
> does not exist, the driver will leave the bridge in its
> current state.
>
> Signed-off-by: Alan Tull <atull@opensource.altera.com>
> Signed-off-by: Matthew Gerlach <mgerlach@altera.com>
> Signed-off-by: Dinh Nguyen <dinguyen@opensource.altera.com>
(...)
> +static inline int _alt_fpga2sdram_enable_set(struct alt_fpga2sdram_data *priv,
> + bool enable)
> +{
> + return regmap_update_bits(priv->sdrctl, ALT_SDR_CTL_FPGAPORTRST_OFST,
> + priv->mask, enable ? priv->mask : 0);
> +}
(...)
> + /* Get f2s bridge configuration saved in handoff register */
> + regmap_read(sysmgr, SYSMGR_ISWGRP_HANDOFF3, &priv->mask);
> +
Could you maybe add some documentation about this implicit information
shared between a bootloader and this driver?
I understand why you do this, but there must be a better way than
depending on something some bootloader wrote in some undocumented
register, no?
The documentation just says:
"These registers are used to store handoff infomation between the
preloader and the OS. These 8 registers can be used to store any
information. The contents of these registers have no impact on the
state of the HPS hardware"
If it is already agreed upon, that a bridge-enable property is okay,
why not add a port-enable property, too?
Regards,
Steffen Trumtrar
--
Pengutronix e.K. | Steffen Trumtrar |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH] usb: gadget: udc: atmel: fix endpoint name
From: Nicolas Ferre @ 2016-09-23 14:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c90099af-2537-cc41-2775-dd2ca41dc070@atmel.com>
Le 16/09/2016 ? 10:36, Nicolas Ferre a ?crit :
> Le 15/09/2016 ? 17:07, Alexandre Belloni a ?crit :
>> Since commit c32b5bcfa3c4 ("ARM: dts: at91: Fix USB endpoint nodes"),
>> atmel_usba_udc fails with:
>>
>> ------------[ cut here ]------------
>> WARNING: CPU: 0 PID: 0 at include/linux/usb/gadget.h:405
>> ecm_do_notify+0x188/0x1a0
>> Modules linked in:
>> CPU: 0 PID: 0 Comm: swapper Not tainted 4.7.0+ #15
>> Hardware name: Atmel SAMA5
>> [<c010ccfc>] (unwind_backtrace) from [<c010a7ec>] (show_stack+0x10/0x14)
>> [<c010a7ec>] (show_stack) from [<c0115c10>] (__warn+0xe4/0xfc)
>> [<c0115c10>] (__warn) from [<c0115cd8>] (warn_slowpath_null+0x20/0x28)
>> [<c0115cd8>] (warn_slowpath_null) from [<c04377ac>] (ecm_do_notify+0x188/0x1a0)
>> [<c04377ac>] (ecm_do_notify) from [<c04379a4>] (ecm_set_alt+0x74/0x1ac)
>> [<c04379a4>] (ecm_set_alt) from [<c042f74c>] (composite_setup+0xfc0/0x19f8)
>> [<c042f74c>] (composite_setup) from [<c04356e8>] (usba_udc_irq+0x8f4/0xd9c)
>> [<c04356e8>] (usba_udc_irq) from [<c013ec9c>] (handle_irq_event_percpu+0x9c/0x158)
>> [<c013ec9c>] (handle_irq_event_percpu) from [<c013ed80>] (handle_irq_event+0x28/0x3c)
>> [<c013ed80>] (handle_irq_event) from [<c01416d4>] (handle_fasteoi_irq+0xa0/0x168)
>> [<c01416d4>] (handle_fasteoi_irq) from [<c013e3f8>] (generic_handle_irq+0x24/0x34)
>> [<c013e3f8>] (generic_handle_irq) from [<c013e640>] (__handle_domain_irq+0x54/0xa8)
>> [<c013e640>] (__handle_domain_irq) from [<c010b214>] (__irq_svc+0x54/0x70)
>> [<c010b214>] (__irq_svc) from [<c0107eb0>] (arch_cpu_idle+0x38/0x3c)
>> [<c0107eb0>] (arch_cpu_idle) from [<c0137300>] (cpu_startup_entry+0x9c/0xdc)
>> [<c0137300>] (cpu_startup_entry) from [<c0900c40>] (start_kernel+0x354/0x360)
>> [<c0900c40>] (start_kernel) from [<20008078>] (0x20008078)
>> ---[ end trace e7cf9dcebf4815a6 ]---
>>
>> Fixes: c32b5bcfa3c4 ("ARM: dts: at91: Fix USB endpoint nodes")
>> Reported-by: Richard Genoud <richard.genoud@gmail.com>
>> Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
>
> Acked-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>
> Felipe, Greg,
> It is clearly a regression and material for 4.8-fixes. But I do know
> that we are very late in the process :-(
> Please do what you can to make it progress before 4.8-final but I'm
> truly aware of the challenge.
Any chance that we can have it (aka ping)?
Bye,
> Thanks to Richard for finding this and Alexandre for the quick correction.
>
> Bye,
>
>> ---
>> drivers/usb/gadget/udc/atmel_usba_udc.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/gadget/udc/atmel_usba_udc.c b/drivers/usb/gadget/udc/atmel_usba_udc.c
>> index bb1f6c8f0f01..45bc997d0711 100644
>> --- a/drivers/usb/gadget/udc/atmel_usba_udc.c
>> +++ b/drivers/usb/gadget/udc/atmel_usba_udc.c
>> @@ -1978,7 +1978,7 @@ static struct usba_ep * atmel_udc_of_init(struct platform_device *pdev,
>> dev_err(&pdev->dev, "of_probe: name error(%d)\n", ret);
>> goto err;
>> }
>> - ep->ep.name = name;
>> + ep->ep.name = kasprintf(GFP_KERNEL, "ep%d", ep->index);
>>
>> ep->ep_regs = udc->regs + USBA_EPT_BASE(i);
>> ep->dma_regs = udc->regs + USBA_DMA_BASE(i);
>>
>
>
--
Nicolas Ferre
^ permalink raw reply
* [GIT PULL] few minor fixes for omap dts files for v4.9 merge window
From: Arnd Bergmann @ 2016-09-23 14:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20160921224907.l2nxg5ynw3rxztlm@atomide.com>
On Wednesday, September 21, 2016 3:49:08 PM CEST Tony Lindgren wrote:
> Few fixes for omap dts files for v4.9 merge window. Let's also add
> the tilcdc quirks:
>
> - Fix typo with recent beagleboard-x15 changes for mmc2_pins_default
>
> - Add am335x blue-and-red-wiring quirk as specified in the binding in
> Documentation/devicetree/bindings/display/tilcdc/tilcdc.txt. Also
> fix up the whitespace formatting for am335x-evmsk.
>
> - Fix for recent igepv5 power button for GPIO_ACTIVE_LOW. Also fix
> up the whitespace formatting for the button
>
Pulled into next/dt, thanks!
Arnd
^ permalink raw reply
* [PATCH 1/2] armv8: aarch32: Execute 32-bit Linux for LayerScape platforms
From: Robin Murphy @ 2016-09-23 14:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <VI1PR0401MB26384246128D6043B93E6E9F8DC80@VI1PR0401MB2638.eurprd04.prod.outlook.com>
On 23/09/16 15:01, Stuart Yoder wrote:
>
>
>> -----Original Message-----
>> From: Robin Murphy [mailto:robin.murphy at arm.com]
>> Sent: Friday, September 23, 2016 8:19 AM
>> To: Stuart Yoder <stuart.yoder@nxp.com>; 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>; 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
>>
>> 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.
>
> Thanks. A question about the switch into aarch32 state... our assumption
> was that the kernel starts at EL2. In this proof of concept we're doing the
> switch to aarch32/EL2 in firmware. And what I'm being told is that the
> firmware aarch64 EL2 code cannot switch to aarch32 EL2 without some
> assistance from EL3 firmware. This is leading us to invent a new
> SMC call to do this.
>
> Did you face this?
Yes, the only way to enter in Hyp is to have the firmware twiddle
SCR_EL3.RW (I simply stuck a disgusting hack directly in ATF's exception
handler, which my dodgy 64-bit header then calls). Otherwise you can
always simply run your own shim at EL2 to drive an AArch32 EL1 (it'll
need to trap and translate subsequent SMC calls for e.g. PSCI).
> If there is such a requirement, it's something begging for standardization.
> Doesn't make sense for multiple divergent approaches for switching from
> aarch64/EL2 to aarch32/EL2.
Perhaps - I did briefly look into how hard it would be to write a proper
SMC service handler to do this (since ATF does have a framework for such
things), but concluded it would be more than 10 minutes' work and just
cheated instead. It's certainly something which could be raised with the
firmware folks.
Robin.
>
> Thanks,
> Stuart
>
^ permalink raw reply
* Regression in next with "mfd: twl6040: The chip does not support bulk access"
From: Tony Lindgren @ 2016-09-23 14:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <139a8c7b-8cfe-fa21-634a-4551511f0cea@ti.com>
* Peter Ujfalusi <peter.ujfalusi@ti.com> [160923 00:21]:
> On 09/22/16 21:07, Tony Lindgren wrote:
> > Hi,
> >
> > Looks like commit 7a17e47f6403 ("mfd: twl6040: The chip does not
> > support bulk access") breaks at least omap4-duovero.
>
> That's odd. I see no such errors on omap4 PandaBoard-ES nor on omap5 uEVM.
> The IRQ status is one register so even in bulk access it is one read. So the
> use_single_rw should have no effect on the access.
Oh it's just one register.
> The only time when regmap would try to use bulk access to twl6040 is when we
> execute regcache_sync() on it after resuming the chip and this would fail at
> the first time when it tries to restore more than one consecutive registers.
>
> I just tested things on next-20160915 and I see no errors at all.
OK interesting.
> > I now get tons of errors:
> >
> > Skipping twl internal clock init and using bootloader value (unknown osc rate)
> > twl 0-0048: PIH (irq 332) nested IRQs
> > of_get_named_gpiod_flags: parsed 'ti,audpwron-gpio' property of node '/ocp/i2c at 48070000/t
> > wl at 4b[0]' - status (0)
> > omap_i2c 48070000.i2c: bus 0 rev0.10 at 400 kHz
> > twl6040 0-004b: Failed to read IRQ status: -16
> > twl6040 0-004b: Failed to read IRQ status: -16
> > twl6040 0-004b: Failed to read IRQ status: -16
> > twl6040 0-004b: Failed to read IRQ status: -16
> > twl6040 0-004b: Failed to read IRQ status: -16
> > twl6040 0-004b: Failed to read IRQ status: -16
> > twl6040 0-004b: Failed to read IRQ status: -16
> > twl6040 0-004b: Failed to read IRQ status: -16
> > twl6040 0-004b: Failed to read IRQ status: -16
> >
> > It seems the regmap irqs don't work with use_single_rw?
So obviously that's a wrong conclusion then.
> > Also seems that twl6040 does support bulk access as things have been
> > working earlier?
>
> Things kind of worked as we had single register reads and writes, but when I
> tried to power down/up the twl6040 the regcache_sync() would fail to restore
> the registers at the first place when we had two or more registers to update
> in bulk mode. In that case regmap gives an error, but I have not been checking
> the return of the regcache_sync() so the chip comes up, but not all settings
> were restored.
>
> > Anyways, can you please revert?
>
> Please don't.
>
> On which linux-next version you are seeing this?
This was with next-20160922. But testing it again this is just another
regression caused by "softirq: fix tasklet_kill() and its users", so adding
Santosh to Cc.
So no need to revert $subject patch.
Regards,
Tony
^ permalink raw reply
* Regression in next with "mfd: twl6040: The chip does not support bulk access"
From: Tony Lindgren @ 2016-09-23 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8b8a49cd-ca7b-4580-58ba-3e05d933853e@ti.com>
* Peter Ujfalusi <peter.ujfalusi@ti.com> [160923 03:20]:
> On 09/23/16 10:20, Peter Ujfalusi wrote:
> > On 09/22/16 21:07, Tony Lindgren wrote:
> >> Hi,
> >>
> >> Looks like commit 7a17e47f6403 ("mfd: twl6040: The chip does not
> >> support bulk access") breaks at least omap4-duovero.
> >
> > That's odd. I see no such errors on omap4 PandaBoard-ES nor on omap5 uEVM.
> > The IRQ status is one register so even in bulk access it is one read. So the
> > use_single_rw should have no effect on the access.
> >
> > The only time when regmap would try to use bulk access to twl6040 is when we
> > execute regcache_sync() on it after resuming the chip and this would fail at
> > the first time when it tries to restore more than one consecutive registers.
> >
> > I just tested things on next-20160915 and I see no errors at all.
>
> Retested on next-20160923 and I see no issue on Panda-ES or omap5-uevm.
>
> My guess is that you receive an interrupt from twl6040 while the chip is
> powered down, the regmap is set to cache only. But this has nothing to do with
> the bulk or non bulk access... Looking at the commit logs and git blame I see
> no recent change in the driver(s) for twl6040 which changed the way it loads
> and/or powers up/down.
OK yeah this is another one caused by "softirq: fix tasklet_kill() and
its users".
Thanks,
Tony
^ permalink raw reply
* [PATCH 1/2] net: qcom/emac: do not use devm on internal phy pdev
From: Timur Tabi @ 2016-09-23 14:27 UTC (permalink / raw)
To: linux-arm-kernel
The platform_device returned by of_find_device_by_node() is not
automatically released when the driver unprobes. Therefore,
managed calls like devm_ioremap_resource() should not be used.
Instead, we manually allocate the resources and then free them
on driver release.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
drivers/net/ethernet/qualcomm/emac/emac-sgmii.c | 42 +++++++++++++++++++------
drivers/net/ethernet/qualcomm/emac/emac.c | 4 +++
2 files changed, 37 insertions(+), 9 deletions(-)
diff --git a/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c b/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c
index 9a9a963..2a095fb 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c
@@ -681,6 +681,7 @@ int emac_sgmii_config(struct platform_device *pdev, struct emac_adapter *adpt)
struct resource *res;
const struct of_device_id *match;
struct device_node *np;
+ int ret;
np = of_parse_phandle(pdev->dev.of_node, "internal-phy", 0);
if (!np) {
@@ -697,26 +698,49 @@ int emac_sgmii_config(struct platform_device *pdev, struct emac_adapter *adpt)
match = of_match_device(emac_sgmii_dt_match, &sgmii_pdev->dev);
if (!match) {
dev_err(&pdev->dev, "unrecognized internal phy node\n");
- return -ENODEV;
+ ret = -ENODEV;
+ goto error_put_device;
}
phy->initialize = (emac_sgmii_initialize)match->data;
/* Base address is the first address */
res = platform_get_resource(sgmii_pdev, IORESOURCE_MEM, 0);
- phy->base = devm_ioremap_resource(&sgmii_pdev->dev, res);
- if (IS_ERR(phy->base))
- return PTR_ERR(phy->base);
+ phy->base = ioremap(res->start, resource_size(res));
+ if (IS_ERR(phy->base)) {
+ ret = PTR_ERR(phy->base);
+ goto error_put_device;
+ }
/* v2 SGMII has a per-lane digital digital, so parse it if it exists */
res = platform_get_resource(sgmii_pdev, IORESOURCE_MEM, 1);
if (res) {
- phy->digital = devm_ioremap_resource(&sgmii_pdev->dev, res);
- if (IS_ERR(phy->base))
- return PTR_ERR(phy->base);
-
+ phy->digital = ioremap(res->start, resource_size(res));
+ if (IS_ERR(phy->digital)) {
+ ret = PTR_ERR(phy->digital);
+ goto error_unmap_base;
+ }
}
- return phy->initialize(adpt);
+ ret = phy->initialize(adpt);
+ if (ret)
+ goto error;
+
+ /* We've remapped the addresses, so we don't need the device any
+ * more. of_find_device_by_node() says we should release it.
+ */
+ put_device(&sgmii_pdev->dev);
+
+ return 0;
+
+error:
+ if (phy->digital)
+ iounmap(phy->digital);
+error_unmap_base:
+ iounmap(phy->base);
+error_put_device:
+ put_device(&sgmii_pdev->dev);
+
+ return ret;
}
diff --git a/drivers/net/ethernet/qualcomm/emac/emac.c b/drivers/net/ethernet/qualcomm/emac/emac.c
index e47d387..429b4cb 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac.c
@@ -723,6 +723,10 @@ static int emac_remove(struct platform_device *pdev)
mdiobus_unregister(adpt->mii_bus);
free_netdev(netdev);
+ if (adpt->phy.digital)
+ iounmap(adpt->phy.digital);
+ iounmap(adpt->phy.base);
+
return 0;
}
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH 2/2] net: qcom/emac: initial ACPI support
From: Timur Tabi @ 2016-09-23 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474640854-1698-1-git-send-email-timur@codeaurora.org>
Add support for reading addresses, interrupts, and _DSD properties
from ACPI tables, just like with device tree. The HID for the
EMAC device itself is QCOM8070. The internal PHY is represented
by a child node with a HID of QCOM8071.
The EMAC also has some complex clock initialization requirements
that are not represented by this patch. This will be addressed
in a future patch.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
drivers/net/ethernet/qualcomm/emac/emac-phy.c | 39 +++++++++++---
drivers/net/ethernet/qualcomm/emac/emac-sgmii.c | 72 ++++++++++++++++++-------
drivers/net/ethernet/qualcomm/emac/emac.c | 60 ++++++++++++++++++++-
3 files changed, 143 insertions(+), 28 deletions(-)
diff --git a/drivers/net/ethernet/qualcomm/emac/emac-phy.c b/drivers/net/ethernet/qualcomm/emac/emac-phy.c
index c412ba9..7c7c3bb 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac-phy.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac-phy.c
@@ -19,6 +19,7 @@
#include <linux/of_mdio.h>
#include <linux/phy.h>
#include <linux/iopoll.h>
+#include <linux/acpi.h>
#include "emac.h"
#include "emac-mac.h"
#include "emac-phy.h"
@@ -163,11 +164,10 @@ static int emac_mdio_write(struct mii_bus *bus, int addr, int regnum, u16 val)
return ret;
}
-/* Configure the MDIO bus and connect the external PHY */
+/* Read phy configuration and initialize it */
int emac_phy_config(struct platform_device *pdev, struct emac_adapter *adpt)
{
struct device_node *np = pdev->dev.of_node;
- struct device_node *phy_np;
struct mii_bus *mii_bus;
int ret;
@@ -183,14 +183,37 @@ int emac_phy_config(struct platform_device *pdev, struct emac_adapter *adpt)
mii_bus->parent = &pdev->dev;
mii_bus->priv = adpt;
- ret = of_mdiobus_register(mii_bus, np);
- if (ret) {
- dev_err(&pdev->dev, "could not register mdio bus\n");
- return ret;
+ if (has_acpi_companion(&pdev->dev)) {
+ u32 phy_addr;
+
+ ret = mdiobus_register(mii_bus);
+ if (ret) {
+ dev_err(&pdev->dev, "could not register mdio bus\n");
+ return ret;
+ }
+ ret = device_property_read_u32(&pdev->dev, "phy-channel",
+ &phy_addr);
+ if (ret)
+ /* If we can't read a valid phy address, then assume
+ * that there is only one phy on this mdio bus.
+ */
+ adpt->phydev = phy_find_first(mii_bus);
+ else
+ adpt->phydev = mdiobus_get_phy(mii_bus, phy_addr);
+
+ } else {
+ struct device_node *phy_np;
+
+ ret = of_mdiobus_register(mii_bus, np);
+ if (ret) {
+ dev_err(&pdev->dev, "could not register mdio bus\n");
+ return ret;
+ }
+
+ phy_np = of_parse_phandle(np, "phy-handle", 0);
+ adpt->phydev = of_phy_find_device(phy_np);
}
- phy_np = of_parse_phandle(np, "phy-handle", 0);
- adpt->phydev = of_phy_find_device(phy_np);
if (!adpt->phydev) {
dev_err(&pdev->dev, "could not find external phy\n");
mdiobus_unregister(mii_bus);
diff --git a/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c b/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c
index 2a095fb..8b3e6c3 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac-sgmii.c
@@ -14,6 +14,7 @@
*/
#include <linux/iopoll.h>
+#include <linux/acpi.h>
#include <linux/of_device.h>
#include "emac.h"
#include "emac-mac.h"
@@ -662,6 +663,24 @@ void emac_sgmii_reset(struct emac_adapter *adpt)
clk_set_rate(adpt->clk[EMAC_CLK_HIGH_SPEED], 125000000);
}
+static int emac_sgmii_acpi_match(struct device *dev, void *data)
+{
+ static const struct acpi_device_id match_table[] = {
+ {
+ .id = "QCOM8071",
+ .driver_data = (kernel_ulong_t)emac_sgmii_init_v2,
+ },
+ {}
+ };
+ const struct acpi_device_id *id = acpi_match_device(match_table, dev);
+ emac_sgmii_initialize *initialize = data;
+
+ if (id)
+ *initialize = (emac_sgmii_initialize)id->driver_data;
+
+ return !!id;
+}
+
static const struct of_device_id emac_sgmii_dt_match[] = {
{
.compatible = "qcom,fsm9900-emac-sgmii",
@@ -679,30 +698,45 @@ int emac_sgmii_config(struct platform_device *pdev, struct emac_adapter *adpt)
struct platform_device *sgmii_pdev = NULL;
struct emac_phy *phy = &adpt->phy;
struct resource *res;
- const struct of_device_id *match;
- struct device_node *np;
int ret;
- np = of_parse_phandle(pdev->dev.of_node, "internal-phy", 0);
- if (!np) {
- dev_err(&pdev->dev, "missing internal-phy property\n");
- return -ENODEV;
- }
+ if (has_acpi_companion(&pdev->dev)) {
+ struct device *dev;
- sgmii_pdev = of_find_device_by_node(np);
- if (!sgmii_pdev) {
- dev_err(&pdev->dev, "invalid internal-phy property\n");
- return -ENODEV;
- }
+ dev = device_find_child(&pdev->dev, &phy->initialize,
+ emac_sgmii_acpi_match);
- match = of_match_device(emac_sgmii_dt_match, &sgmii_pdev->dev);
- if (!match) {
- dev_err(&pdev->dev, "unrecognized internal phy node\n");
- ret = -ENODEV;
- goto error_put_device;
- }
+ if (!dev) {
+ dev_err(&pdev->dev, "cannot find internal phy node\n");
+ return -ENODEV;
+ }
- phy->initialize = (emac_sgmii_initialize)match->data;
+ sgmii_pdev = to_platform_device(dev);
+ } else {
+ const struct of_device_id *match;
+ struct device_node *np;
+
+ np = of_parse_phandle(pdev->dev.of_node, "internal-phy", 0);
+ if (!np) {
+ dev_err(&pdev->dev, "missing internal-phy property\n");
+ return -ENODEV;
+ }
+
+ sgmii_pdev = of_find_device_by_node(np);
+ if (!sgmii_pdev) {
+ dev_err(&pdev->dev, "invalid internal-phy property\n");
+ return -ENODEV;
+ }
+
+ match = of_match_device(emac_sgmii_dt_match, &sgmii_pdev->dev);
+ if (!match) {
+ dev_err(&pdev->dev, "unrecognized internal phy node\n");
+ ret = -ENODEV;
+ goto error_put_device;
+ }
+
+ phy->initialize = (emac_sgmii_initialize)match->data;
+ }
/* Base address is the first address */
res = platform_get_resource(sgmii_pdev, IORESOURCE_MEM, 0);
diff --git a/drivers/net/ethernet/qualcomm/emac/emac.c b/drivers/net/ethernet/qualcomm/emac/emac.c
index 429b4cb..4cde237 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac.c
@@ -22,6 +22,7 @@
#include <linux/of_device.h>
#include <linux/phy.h>
#include <linux/platform_device.h>
+#include <linux/acpi.h>
#include "emac.h"
#include "emac-mac.h"
#include "emac-phy.h"
@@ -570,6 +571,49 @@ static int emac_probe_resources(struct platform_device *pdev,
return 0;
}
+/* Get the resources */
+static int emac_probe_acpi_resources(struct platform_device *pdev,
+ struct emac_adapter *adpt)
+{
+ struct net_device *netdev = adpt->netdev;
+ struct resource *res;
+ char maddr[ETH_ALEN];
+ int ret = 0;
+
+ /* get mac address */
+
+ ret = device_property_read_u8_array(&pdev->dev, "mac-address",
+ maddr, ETH_ALEN);
+ if (ret)
+ eth_hw_addr_random(netdev);
+ else
+ ether_addr_copy(netdev->dev_addr, maddr);
+
+ ret = platform_get_irq(pdev, 0);
+ if (ret < 0) {
+ dev_err(&pdev->dev,
+ "error: missing irq resource (error=%i)\n", ret);
+ return ret;
+ }
+ adpt->irq.irq = ret;
+
+ /* get base register addresses */
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ adpt->base = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(adpt->base))
+ return PTR_ERR(adpt->base);
+
+ /* get CSR register addresses */
+ res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
+ adpt->csr = devm_ioremap_resource(&pdev->dev, res);
+ if (IS_ERR(adpt->csr))
+ return PTR_ERR(adpt->csr);
+
+ netdev->base_addr = (unsigned long)adpt->base;
+
+ return 0;
+}
+
static const struct of_device_id emac_dt_match[] = {
{
.compatible = "qcom,fsm9900-emac",
@@ -577,6 +621,16 @@ static const struct of_device_id emac_dt_match[] = {
{}
};
+#if IS_ENABLED(CONFIG_ACPI)
+static const struct acpi_device_id emac_acpi_match[] = {
+ {
+ .id = "QCOM8070",
+ },
+ {}
+};
+MODULE_DEVICE_TABLE(acpi, emac_acpi_match);
+#endif
+
static int emac_probe(struct platform_device *pdev)
{
struct net_device *netdev;
@@ -620,7 +674,10 @@ static int emac_probe(struct platform_device *pdev)
adpt->irq.mask = RX_PKT_INT0 | IMR_NORMAL_MASK;
- ret = emac_probe_resources(pdev, adpt);
+ if (has_acpi_companion(&pdev->dev))
+ ret = emac_probe_acpi_resources(pdev, adpt);
+ else
+ ret = emac_probe_resources(pdev, adpt);
if (ret)
goto err_undo_netdev;
@@ -736,6 +793,7 @@ static struct platform_driver emac_platform_driver = {
.driver = {
.name = "qcom-emac",
.of_match_table = emac_dt_match,
+ .acpi_match_table = ACPI_PTR(emac_acpi_match),
},
};
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH v6 4/4] arm/arm64: arch_timer: Use archdata to indicate vdso suitability
From: Russell King - ARM Linux @ 2016-09-23 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1474533318-7796-4-git-send-email-oss@buserror.net>
It helps to add the appropriate people to your email if you want to get
a change into the kernel. Will has had to point this message out to me.
On Thu, Sep 22, 2016 at 03:35:18AM -0500, Scott Wood wrote:
> Instead of comparing the name to a magic string, use archdata to
> explicitly communicate whether the arch timer is suitable for
> direct vdso access.
>
> Signed-off-by: Scott Wood <oss@buserror.net>
> Acked-by: Will Deacon <will.deacon@arm.com>
> ---
> arch/arm/Kconfig | 1 +
> arch/arm/include/asm/clocksource.h | 8 ++++++++
> arch/arm/kernel/vdso.c | 2 +-
> arch/arm64/Kconfig | 1 +
> arch/arm64/include/asm/clocksource.h | 8 ++++++++
> arch/arm64/kernel/vdso.c | 2 +-
> drivers/clocksource/arm_arch_timer.c | 11 +++--------
> 7 files changed, 23 insertions(+), 10 deletions(-)
> create mode 100644 arch/arm/include/asm/clocksource.h
> create mode 100644 arch/arm64/include/asm/clocksource.h
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index a9c4e48..b2113c2 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -1,6 +1,7 @@
> config ARM
> bool
> default y
> + select ARCH_CLOCKSOURCE_DATA
> select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
> select ARCH_HAS_DEVMEM_IS_ALLOWED
> select ARCH_HAS_ELF_RANDOMIZE
> diff --git a/arch/arm/include/asm/clocksource.h b/arch/arm/include/asm/clocksource.h
> new file mode 100644
> index 0000000..0b350a7
> --- /dev/null
> +++ b/arch/arm/include/asm/clocksource.h
> @@ -0,0 +1,8 @@
> +#ifndef _ASM_CLOCKSOURCE_H
> +#define _ASM_CLOCKSOURCE_H
> +
> +struct arch_clocksource_data {
> + bool vdso_direct; /* Usable for direct VDSO access? */
> +};
> +
> +#endif
> diff --git a/arch/arm/kernel/vdso.c b/arch/arm/kernel/vdso.c
> index 994e971..a0affd1 100644
> --- a/arch/arm/kernel/vdso.c
> +++ b/arch/arm/kernel/vdso.c
> @@ -270,7 +270,7 @@ static bool tk_is_cntvct(const struct timekeeper *tk)
> if (!IS_ENABLED(CONFIG_ARM_ARCH_TIMER))
> return false;
>
> - if (strcmp(tk->tkr_mono.clock->name, "arch_sys_counter") != 0)
> + if (!tk->tkr_mono.clock->archdata.vdso_direct)
> return false;
>
> return true;
For the ARM bits:
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
--
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
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