* [PATCH] MAINTAINERS: Update Broadcom Vulcan maintainer email
From: Florian Fainelli @ 2016-11-06 0:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478249673-8163-1-git-send-email-c.jayachandran@gmail.com>
Le 04/11/2016 ? 01:54, Jayachandran C a ?crit :
> Update Broadcom Vulcan maintainer's email address, the broadcom.com
> address is no longer valid.
>
> Signed-off-by: Jayachandran C <c.jayachandran@gmail.com>
Applied; thanks JC!
--
Florian
^ permalink raw reply
* [PATCH 13/22] mtd: nand: lpc32xx: return error code of nand_scan_ident/tail() on error
From: Vladimir Zapolskiy @ 2016-11-06 1:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478256190-7452-14-git-send-email-yamada.masahiro@socionext.com>
On 11/04/2016 12:43 PM, Masahiro Yamada wrote:
> The nand_scan_ident/tail() returns an appropriate error value when
> it fails. Use it instead of the fixed error code -ENXIO.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
Acked-by: Vladimir Zapolskiy <vz@mleia.com>
Thank you for the change.
--
With best wishes,
Vladimir
^ permalink raw reply
* [PATCH v3] ARM: bcm2835: Add names for the Raspberry Pi GPIO lines
From: Stephen Warren @ 2016-11-06 3:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161027165246.23936-1-eric@anholt.net>
On 10/27/2016 10:52 AM, Eric Anholt wrote:
> From: Linus Walleij <linus.walleij@linaro.org>
>
> The idea is to give useful names to GPIO lines that an implementer
> will be using from userspace, e.g. for maker type projects. These are
> user-visible using tools/gpio/lsgpio.c
> arch/arm/boot/dts/bcm2835-rpi-a-plus.dts | 65 +++++++++++++++++++++++++++++++
> arch/arm/boot/dts/bcm2835-rpi-a.dts | 67 ++++++++++++++++++++++++++++++++
> arch/arm/boot/dts/bcm2835-rpi-b-plus.dts | 66 +++++++++++++++++++++++++++++++
> arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts | 66 +++++++++++++++++++++++++++++++
> arch/arm/boot/dts/bcm2835-rpi-b.dts | 67 ++++++++++++++++++++++++++++++++
Aren't the A and B rev 2 pinouts the same. If so, why duplicate the
content between the files instead of creating an inclue file? Same for
A+, B+, Pi 2, and Pi 3. Shouldn't this patch update the Pi 2 and Pi 3
DTs too?
> diff --git a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts
> &gpio {
> + /*
> + * This is based on the unreleased schematic for the Model A+.
> + *
> + * Legend:
> + * "NC" = not connected (no rail from the SoC)
> + * "FOO" = GPIO line named "FOO" on the schematic
> + * "FOO_N" = GPIO line named "FOO" on schematic, active low
> + */
> + gpio-line-names = "SDA0",
> + "SCL0",
> diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts
> &gpio {
> + /*
> + * Taken from Raspberry-Pi-B-Plus-V1.2-Schematics.pdf
> + * RPI-BPLUS sheet 1
> + *
> + * Legend:
> + * "NC" = not connected (no rail from the SoC)
> + * "FOO" = GPIO line named "FOO" on the schematic
> + * "FOO_N" = GPIO line named "FOO" on schematic, active low
> + */
> + gpio-line-names = "ID_SD",
> + "ID_SC",
I think the whole point of naming GPIOs is to give users the same
experience across the different boards where the same semantics exist in
HW. Both the A+ and B+ use GPIO0/1 (a/k/a ID_SD/ID_SC a/k/a SDA0/SCL0)
for the same semantic purpose and are exposed in the same externally
visible way (same pins on the expansion header); the board ID EEPROM.
Therefore I assert the names of these GPIOs should be identical on all
boards that use them for that purpose, to allow SW (or human knowledge)
portability between the boards.
> + "GPIO17",
This pin is known as GPIO_GEN0 on the expansion header. Given the
expansion header is all end-users likely care about, and other pins
(e.g. SPI_CE1_N) are named after the expansion header, shouldn't this
patch use the GPIO expansion header naming for all pins that are routed
to that header?
^ permalink raw reply
* [PATCH 2/6] pinctrl: rockchip: add support for rk1108
From: Linus Walleij @ 2016-11-06 10:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478176470-11956-1-git-send-email-andy.yan@rock-chips.com>
On Thu, Nov 3, 2016 at 1:34 PM, Andy Yan <andy.yan@rock-chips.com> wrote:
> Add basic support for rk1108 soc
>
> Signed-off-by: Andy Yan <andy.yan@rock-chips.com>
I only see this patch from the series, I guess this is the only
patch affecting pin control so thanks for not spamming :)
Please resend with Heiko's requested fixes and his Reviewed-by
tag and I will apply it.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH RFC] ARM: dts: add support for Turris Omnia
From: Andrew Lunn @ 2016-11-06 10:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161105220848.k6rrjmvvhdaeduma@perseus.defre.kleine-koenig.org>
> Will do for v2. arch/arm/boot/dts/keystone-* needs fixing in this
> regard, too.
There is a whitelist of compatible strings which are ignored, for
backwards compatibility. See of_mdiobus_child_is_phy(). It would be
nice to fix keystone, but it is not required.
Andrew
^ permalink raw reply
* [Bug] ARM: mxs: STI: console can't wake up from freeze
From: Stefan Wahren @ 2016-11-06 10:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161105180542.GE1041@n2100.armlinux.org.uk>
Hi,
> Russell King - ARM Linux <linux@armlinux.org.uk> hat am 5. November 2016 um
> 19:05 geschrieben:
>
>
> On Sat, Nov 05, 2016 at 04:28:37PM +0100, Stefan Wahren wrote:
> > As i wrote in my email before, i added a pr_info() into freeze_wake.
> > But i never see the output of this message. So i assume freeze_wake
> > is never called. Again, how could this happen?
>
> Hmm, so the bit that you're getting stuck on is:
>
> wait_event(suspend_freeze_wait_head,
> suspend_freeze_state == FREEZE_STATE_WAKE);
>
thanks for all the feedback. The real cause for this issue is in the irqchip
driver. I fixed it with this patch:
diff --git a/drivers/irqchip/irq-mxs.c b/drivers/irqchip/irq-mxs.c
index 1730470..05fa9f7 100644
--- a/drivers/irqchip/irq-mxs.c
+++ b/drivers/irqchip/irq-mxs.c
@@ -131,12 +131,16 @@ static void asm9260_unmask_irq(struct irq_data *d)
.irq_ack = icoll_ack_irq,
.irq_mask = icoll_mask_irq,
.irq_unmask = icoll_unmask_irq,
+ .flags = IRQCHIP_MASK_ON_SUSPEND |
+ IRQCHIP_SKIP_SET_WAKE,
};
static struct irq_chip asm9260_icoll_chip = {
.irq_ack = icoll_ack_irq,
.irq_mask = asm9260_mask_irq,
.irq_unmask = asm9260_unmask_irq,
+ .flags = IRQCHIP_MASK_ON_SUSPEND |
+ IRQCHIP_SKIP_SET_WAKE,
};
asmlinkage void __exception_irq_entry icoll_handle_irq(struct pt_regs *regs)
^ permalink raw reply related
* [RFC PATCH] ARM: dts: add panel and tcon nodes to Allwinner A33 Q8 tablet dts
From: Icenowy Zheng @ 2016-11-06 11:11 UTC (permalink / raw)
To: linux-arm-kernel
All A33 Q8 tablets features a LCD panel, with a resolution of either
800x480 or 1024x600.
Add "bone" device nodes to the device tree.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
Maybe it will be better to add them to sun8i-q8-reference-tablet.dtsi, as
these pin configurations are part of reference design of both A23 and A33,
not only restricted to Q8.
The DTS file is tested by me, after cherry-picks this patch from Chen-Yu Tsai:
https://github.com/wens/linux/commit/2823b887a289fbee5f97f3c6b45ed6c74a6368c6
And add these commands to my U-Boot boot command:
fdt addr 0x43000000
fdt resize
fdt set /panel compatible "urt,umsh-8596md-t"
fdt set /panel status "okay"
fdt set /display-engine status "okay"
fdt set /soc at 01c00000/lcd-controller at 01c0c000 status "okay"
arch/arm/boot/dts/sun8i-a33-q8-tablet.dts | 44 +++++++++++++++++++++++++++++++
1 file changed, 44 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a33-q8-tablet.dts b/arch/arm/boot/dts/sun8i-a33-q8-tablet.dts
index b0bc236..871a20c 100644
--- a/arch/arm/boot/dts/sun8i-a33-q8-tablet.dts
+++ b/arch/arm/boot/dts/sun8i-a33-q8-tablet.dts
@@ -47,4 +47,48 @@
/ {
model = "Q8 A33 Tablet";
compatible = "allwinner,q8-a33", "allwinner,sun8i-a33";
+
+ panel: panel {
+ /* compatible should be set according to the panel */
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_en_q8>;
+ backlight = <&backlight>;
+ enable-gpios = <&pio 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */
+ power-supply = <®_dc1sw>;
+ status = "disabled";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port at 0 {
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ panel_input: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&tcon0_out_lcd>;
+ };
+ };
+ };
+};
+
+&tcon0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&lcd_rgb666_pins>;
+};
+
+&tcon0_out {
+ tcon0_out_lcd: endpoint at 0 {
+ reg = <0>;
+ remote-endpoint = <&panel_input>;
+ };
+};
+
+&pio {
+ lcd_en_q8: lcd_en at 0 {
+ allwinner,pins = "PH7";
+ allwinner,function = "gpio_out";
+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
+ };
};
--
2.10.1
^ permalink raw reply related
* [PATCH v2 1/1] ARM: dmaengine: sun6i: share the dma driver with sun50i
From: Maxime Ripard @ 2016-11-06 13:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161105080548.GA32546@arx12>
On Sat, Nov 05, 2016 at 04:05:48PM +0800, Hao Zhang wrote:
> Add soc a64 dma support.
>
> Signed-off-by: Hao Zhang <hao5781286@gmail.com>
> ---
> drivers/dma/sun6i-dma.c | 19 +++++++++++++++++++
> 1 file changed, 19 insertions(+)
>
> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> index 8346199..00fcfc7 100644
> --- a/drivers/dma/sun6i-dma.c
> +++ b/drivers/dma/sun6i-dma.c
> @@ -1028,11 +1028,23 @@ static struct sun6i_dma_config sun8i_h3_dma_cfg = {
> .nr_max_vchans = 34,
> };
>
> +/*
> + * The A64 has 8 physical channels, a maximum DRQ port id of 27,
> + * and a total of 38 usable source and destination endpoints.
> + */
> +
> +static struct sun6i_dma_config sun50i_a64_dma_cfg = {
> + .nr_max_channels = 8,
> + .nr_max_requests = 27,
> + .nr_max_vchans = 38,
> +};
> +
> static const struct of_device_id sun6i_dma_match[] = {
> { .compatible = "allwinner,sun6i-a31-dma", .data = &sun6i_a31_dma_cfg },
> { .compatible = "allwinner,sun8i-a23-dma", .data = &sun8i_a23_dma_cfg },
> { .compatible = "allwinner,sun8i-a83t-dma", .data = &sun8i_a83t_dma_cfg },
> { .compatible = "allwinner,sun8i-h3-dma", .data = &sun8i_h3_dma_cfg },
> + { .compatible = "allwinner,sun50i-a64-dma", .data = &sun50i_a64_dma_cfg },
You need to add that compatible to the DT binding documentation.
> { /* sentinel */ }
> };
> MODULE_DEVICE_TABLE(of, sun6i_dma_match);
> @@ -1110,6 +1122,13 @@ static int sun6i_dma_probe(struct platform_device *pdev)
> sdc->slave.dst_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
> BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
> BIT(DMA_SLAVE_BUSWIDTH_4_BYTES);
> +
> + if (of_device_is_compatible(pdev->dev.of_node,
> + "allwinner,sun50i-a64-dma")) {
> + sdc->slave.src_addr_widths |= BIT(DMA_SLAVE_BUSWIDTH_8_BYTES);
> + sdc->slave.dst_addr_widths |= BIT(DMA_SLAVE_BUSWIDTH_8_BYTES);
> + }
> +
You'll also need to change convert_buswidth, it will reject any width
higher than 4 bytes.
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: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161106/61c65236/attachment.sig>
^ permalink raw reply
* [RFC PATCH] ARM: dts: add panel and tcon nodes to Allwinner A33 Q8 tablet dts
From: Hans de Goede @ 2016-11-06 14:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161106111119.14927-1-icenowy@aosc.xyz>
Hi,
On 06-11-16 12:11, Icenowy Zheng wrote:
> All A33 Q8 tablets features a LCD panel, with a resolution of either
> 800x480 or 1024x600.
>
> Add "bone" device nodes to the device tree.
Bone ?
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
He, as discussed in the other thread since sun8i-a33-q8-tablet.dts
is used for both 800x480 and 1024x600 versions we really need to
introduce new sun8i-a33-q8-tablet-800x600.dts and
sun8i-a33-q8-tablet-1024x600.dts files, which include
sun8i-a33-q8-tablet.dts and then add just the panel bits; and patch
newer u-boots to use those instead.
This way people who stick with an old u-boot will just not get
the drm driver, rather then all of a sudden getting a wrong
resolution.
Icenowy, can you please also submit a matching u-boot patch
(both the new dts file, as well as updating the defconfig you
use to the new dts file)?
Regards,
Hans
> ---
>
> Maybe it will be better to add them to sun8i-q8-reference-tablet.dtsi, as
> these pin configurations are part of reference design of both A23 and A33,
> not only restricted to Q8.
>
> The DTS file is tested by me, after cherry-picks this patch from Chen-Yu Tsai:
> https://github.com/wens/linux/commit/2823b887a289fbee5f97f3c6b45ed6c74a6368c6
>
> And add these commands to my U-Boot boot command:
>
> fdt addr 0x43000000
> fdt resize
> fdt set /panel compatible "urt,umsh-8596md-t"
> fdt set /panel status "okay"
> fdt set /display-engine status "okay"
> fdt set /soc at 01c00000/lcd-controller at 01c0c000 status "okay"
>
> arch/arm/boot/dts/sun8i-a33-q8-tablet.dts | 44 +++++++++++++++++++++++++++++++
> 1 file changed, 44 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-a33-q8-tablet.dts b/arch/arm/boot/dts/sun8i-a33-q8-tablet.dts
> index b0bc236..871a20c 100644
> --- a/arch/arm/boot/dts/sun8i-a33-q8-tablet.dts
> +++ b/arch/arm/boot/dts/sun8i-a33-q8-tablet.dts
> @@ -47,4 +47,48 @@
> / {
> model = "Q8 A33 Tablet";
> compatible = "allwinner,q8-a33", "allwinner,sun8i-a33";
> +
> + panel: panel {
> + /* compatible should be set according to the panel */
> + pinctrl-names = "default";
> + pinctrl-0 = <&lcd_en_q8>;
> + backlight = <&backlight>;
> + enable-gpios = <&pio 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */
> + power-supply = <®_dc1sw>;
> + status = "disabled";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port at 0 {
> + reg = <0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + panel_input: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <&tcon0_out_lcd>;
> + };
> + };
> + };
> +};
> +
> +&tcon0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&lcd_rgb666_pins>;
> +};
> +
> +&tcon0_out {
> + tcon0_out_lcd: endpoint at 0 {
> + reg = <0>;
> + remote-endpoint = <&panel_input>;
> + };
> +};
> +
> +&pio {
> + lcd_en_q8: lcd_en at 0 {
> + allwinner,pins = "PH7";
> + allwinner,function = "gpio_out";
> + allwinner,drive = <SUN4I_PINCTRL_10_MA>;
> + allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
> + };
> };
>
^ permalink raw reply
* [Bug] ARM: mxs: STI: console can't wake up from freeze
From: Daniel Lezcano @ 2016-11-06 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <381813296.167766.9867e3e7-5710-4844-a098-6f44bd852a6d.open-xchange@email.1und1.de>
On 06/11/2016 11:20, Stefan Wahren wrote:
> Hi,
>
>> Russell King - ARM Linux <linux@armlinux.org.uk> hat am 5. November 2016 um
>> 19:05 geschrieben:
>>
>>
>> On Sat, Nov 05, 2016 at 04:28:37PM +0100, Stefan Wahren wrote:
>>> As i wrote in my email before, i added a pr_info() into freeze_wake.
>>> But i never see the output of this message. So i assume freeze_wake
>>> is never called. Again, how could this happen?
>>
>> Hmm, so the bit that you're getting stuck on is:
>>
>> wait_event(suspend_freeze_wait_head,
>> suspend_freeze_state == FREEZE_STATE_WAKE);
>>
>
> thanks for all the feedback. The real cause for this issue is in the irqchip
> driver. I fixed it with this patch:
Mind to give some details ?
> diff --git a/drivers/irqchip/irq-mxs.c b/drivers/irqchip/irq-mxs.c
> index 1730470..05fa9f7 100644
> --- a/drivers/irqchip/irq-mxs.c
> +++ b/drivers/irqchip/irq-mxs.c
> @@ -131,12 +131,16 @@ static void asm9260_unmask_irq(struct irq_data *d)
> .irq_ack = icoll_ack_irq,
> .irq_mask = icoll_mask_irq,
> .irq_unmask = icoll_unmask_irq,
> + .flags = IRQCHIP_MASK_ON_SUSPEND |
> + IRQCHIP_SKIP_SET_WAKE,
> };
>
> static struct irq_chip asm9260_icoll_chip = {
> .irq_ack = icoll_ack_irq,
> .irq_mask = asm9260_mask_irq,
> .irq_unmask = asm9260_unmask_irq,
> + .flags = IRQCHIP_MASK_ON_SUSPEND |
> + IRQCHIP_SKIP_SET_WAKE,
> };
>
> asmlinkage void __exception_irq_entry icoll_handle_irq(struct pt_regs *regs)
>
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* imx6: PCIe imx6_pcie_assert_core_reset() hangs after watchdog reset
From: Philippe De Muyter @ 2016-11-06 15:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1427377198.3378.16.camel@pengutronix.de>
Hi ARM i.MX6q experts,
sorry to come back with an old problem. I work with with two
different custom boards, designed after the SabreSD board with imx6dl
and imx6q cpus, and I have exactly the same problem : linux kernel hangs
in imx6_pcie_assert_core_reset() at the line :
val = readl(pp->dbi_base + PCIE_PL_PFLR);
this happens constantly after a watchdog reset, and also
sometimes (or on some boards) after a reboot. As we know that
U-Boot on our boards will never mess with the PCI setup, and
that if the PCIe block is configured, it has certainly be
configured by the previous kernel session, I have merely disabled the
code block trying to put back the PCIe block into configurable state.
I have no problem so far, but do you agree that this is a valid fix ?
I use either v3.17 or Freescale's 4.1.15_1.2.0_ga
Best Regards,
Philippe
On Thu, Mar 26, 2015 at 12:39:58PM +0000, Lucas Stach wrote:
> Hi Tim,
>
> Am Donnerstag, den 26.03.2015, 06:23 -0700 schrieb Tim Harvey:
> > On Thu, Mar 26, 2015 at 4:06 AM, Lucas Stach <l.stach@pengutronix.de> wrote:
> > > Am Mittwoch, den 25.03.2015, 11:32 +0100 schrieb Stefan Roese:
> > > Okay, I've looked a bit into this and it seems there is no easy solution
> > > available. It is really unfortunate that the WD reset doesn't reset the
> > > GPR registers. Also I have no idea if the WD reset properly resets the
> > > PCIe core, as the reset signal of this core is only wired to the POR
> > > line.
> > >
> > > To fix this (almost) properly we would have to change the complete init
> > > order of the core, which isn't an easy task, as experience has shown
> > > that even small changes in that area can prevent the link from coming up
> > > under certain circumstances.
> > >
> > > Which brings me back to my earlier assertion that WD reset should really
> > > be done through the PMIC. That's yet another case of a WD making the
> > > overall system more instable.
> > >
> > > I think the easiest workaround for now is to detect the WD reset in your
> > > bootloader and bash the expected default values into the GPR bits.
> > >
> > > Regards,
> > > Lucas
> >
> > Lucas,
> >
> > There are many boards out there that unfortunately don't reset PMIC's
> > properly, IMHO due to a confusing reference design from Freescale.
> >
> > Using the WDOGx_WRSR register we can detect the reason for reset:
> > Bit 4 - POR - Power on reset
> > Bit 1 - TOUT - Watchdog timeout
> > Bit 0 - SFTW - Software reset (used in machine_restart)
> >
> > Can we reset the GPR registers based on bits 0 or 1 set, or use these
> > as further qualifiers in the WAR?
> >
> Doing it in the kernel is too late. This WAR is specifically to work
> around bootloaders leaving the PCI link running when jumping into the
> kernel. We use the GPR bits to detect if the bootloader has touched the
> PCIe core. Unfortunately we see the same signature if the kernel touched
> PCIe and the system got reset by the WD.
>
> If we reset the GPR bits depending on the reset reason register in the
> kernel we have no way to know if the bootloader has touched the PCIe
> core after a WD reset (in which case we still need to apply the WAR). So
> the only way to keep the WAR working while cleaning out bad WD reset
> behavior is to reset the GPR bits in the bootloader, before the
> bootloader itself may touch the PCIe core.
>
> It may be possible to come up with a solution for this in the kernel by
> looking at the PCIe clock status when entering the kernel, but this
> means that we scatter even more WAR code for the bad Freescale PCIe
> integration throughout the kernel, as such code has to go into the
> platform as we don't have the required information at hand in the PCI
> driver. So I'm not really thrilled by thinking about doing it in the
> kernel.
>
> Regards,
> Lucas
>
> --
> Pengutronix e.K. | Lucas Stach |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
Philippe De Muyter +32 2 6101532 Macq SA rue de l'Aeronef 2 B-1140 Bruxelles
^ permalink raw reply
* [RFC PATCH] ARM: dts: add panel and tcon nodes to Allwinner A33 Q8 tablet dts
From: Icenowy Zheng @ 2016-11-06 16:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <948897e3-12a2-b02c-ed26-929921ff04b2@redhat.com>
06.11.2016, 22:27, "Hans de Goede" <hdegoede@redhat.com>:
> Hi,
>
> On 06-11-16 12:11, Icenowy Zheng wrote:
>> ?All A33 Q8 tablets features a LCD panel, with a resolution of either
>> ?800x480 or 1024x600.
>>
>> ?Add "bone" device nodes to the device tree.
>
> Bone ?
>
>> ?Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
>
> He, as discussed in the other thread since sun8i-a33-q8-tablet.dts
> is used for both 800x480 and 1024x600 versions we really need to
> introduce new sun8i-a33-q8-tablet-800x600.dts and
> sun8i-a33-q8-tablet-1024x600.dts files, which include
> sun8i-a33-q8-tablet.dts and then add just the panel bits; and patch
> newer u-boots to use those instead.
>
> This way people who stick with an old u-boot will just not get
> the drm driver, rather then all of a sudden getting a wrong
> resolution.
>
> Icenowy, can you please also submit a matching u-boot patch
> (both the new dts file, as well as updating the defconfig you
> ??use to the new dts file)?
Could you choose a compatible for 1024x600 variant?
(Since I have never such a Q8 tablet)
>
> Regards,
>
> Hans
>
>> ?---
>>
>> ?Maybe it will be better to add them to sun8i-q8-reference-tablet.dtsi, as
>> ?these pin configurations are part of reference design of both A23 and A33,
>> ?not only restricted to Q8.
>>
>> ?The DTS file is tested by me, after cherry-picks this patch from Chen-Yu Tsai:
>> ?https://github.com/wens/linux/commit/2823b887a289fbee5f97f3c6b45ed6c74a6368c6
>>
>> ?And add these commands to my U-Boot boot command:
>>
>> ?fdt addr 0x43000000
>> ?fdt resize
>> ?fdt set /panel compatible "urt,umsh-8596md-t"
>> ?fdt set /panel status "okay"
>> ?fdt set /display-engine status "okay"
>> ?fdt set /soc at 01c00000/lcd-controller at 01c0c000 status "okay"
>>
>> ??arch/arm/boot/dts/sun8i-a33-q8-tablet.dts | 44 +++++++++++++++++++++++++++++++
>> ??1 file changed, 44 insertions(+)
>>
>> ?diff --git a/arch/arm/boot/dts/sun8i-a33-q8-tablet.dts b/arch/arm/boot/dts/sun8i-a33-q8-tablet.dts
>> ?index b0bc236..871a20c 100644
>> ?--- a/arch/arm/boot/dts/sun8i-a33-q8-tablet.dts
>> ?+++ b/arch/arm/boot/dts/sun8i-a33-q8-tablet.dts
>> ?@@ -47,4 +47,48 @@
>> ??/ {
>> ??????????model = "Q8 A33 Tablet";
>> ??????????compatible = "allwinner,q8-a33", "allwinner,sun8i-a33";
>> ?+
>> ?+ panel: panel {
>> ?+ /* compatible should be set according to the panel */
>> ?+ pinctrl-names = "default";
>> ?+ pinctrl-0 = <&lcd_en_q8>;
>> ?+ backlight = <&backlight>;
>> ?+ enable-gpios = <&pio 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */
>> ?+ power-supply = <®_dc1sw>;
>> ?+ status = "disabled";
>> ?+ #address-cells = <1>;
>> ?+ #size-cells = <0>;
>> ?+
>> ?+ port at 0 {
>> ?+ reg = <0>;
>> ?+ #address-cells = <1>;
>> ?+ #size-cells = <0>;
>> ?+
>> ?+ panel_input: endpoint at 0 {
>> ?+ reg = <0>;
>> ?+ remote-endpoint = <&tcon0_out_lcd>;
>> ?+ };
>> ?+ };
>> ?+ };
>> ?+};
>> ?+
>> ?+&tcon0 {
>> ?+ pinctrl-names = "default";
>> ?+ pinctrl-0 = <&lcd_rgb666_pins>;
>> ?+};
>> ?+
>> ?+&tcon0_out {
>> ?+ tcon0_out_lcd: endpoint at 0 {
>> ?+ reg = <0>;
>> ?+ remote-endpoint = <&panel_input>;
>> ?+ };
>> ?+};
>> ?+
>> ?+&pio {
>> ?+ lcd_en_q8: lcd_en at 0 {
>> ?+ allwinner,pins = "PH7";
>> ?+ allwinner,function = "gpio_out";
>> ?+ allwinner,drive = <SUN4I_PINCTRL_10_MA>;
>> ?+ allwinner,pull = <SUN4I_PINCTRL_NO_PULL>;
>> ?+ };
>> ??};
^ permalink raw reply
* imx6: PCIe imx6_pcie_assert_core_reset() hangs after watchdog reset
From: Fabio Estevam @ 2016-11-06 16:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161106153117.GA22538@frolo.macqel>
On Sun, Nov 6, 2016 at 1:31 PM, Philippe De Muyter <phdm@macq.eu> wrote:
> I use either v3.17 or Freescale's 4.1.15_1.2.0_ga
These kernel versions are not supported by the kernel community.
Do you observe issues with 4.8.6 or 4.9-rc4?
^ permalink raw reply
* [PATCH 1/2] clk: sunxi-ng: Fix CPUX clock for the A23/A33
From: Icenowy Zheng @ 2016-11-06 17:29 UTC (permalink / raw)
To: linux-arm-kernel
The CPUX clock of A23/33 CCU driver forgot to add CLK_SET_RATE_PARENT
flag, which makes its frequency fail to change (as part of cpu thermal
throttle).
Fix it by add this flag.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
Patch 4.9-rc too.
drivers/clk/sunxi-ng/ccu-sun8i-a23.c | 2 +-
drivers/clk/sunxi-ng/ccu-sun8i-a33.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a23.c b/drivers/clk/sunxi-ng/ccu-sun8i-a23.c
index 2646d98..44c4775 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-a23.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-a23.c
@@ -163,7 +163,7 @@ static SUNXI_CCU_NM_WITH_FRAC_GATE_LOCK(pll_de_clk, "pll-de",
static const char * const cpux_parents[] = { "osc32k", "osc24M",
"pll-cpux" , "pll-cpux" };
static SUNXI_CCU_MUX(cpux_clk, "cpux", cpux_parents,
- 0x050, 16, 2, CLK_IS_CRITICAL);
+ 0x050, 16, 2, CLK_IS_CRITICAL | CLK_SET_RATE_PARENT);
static SUNXI_CCU_M(axi_clk, "axi", "cpux", 0x050, 0, 2, 0);
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a33.c b/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
index 96b40ca..59cfdc8 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
@@ -170,7 +170,7 @@ static SUNXI_CCU_N_WITH_GATE_LOCK(pll_ddr1_clk, "pll-ddr1",
static const char * const cpux_parents[] = { "osc32k", "osc24M",
"pll-cpux" , "pll-cpux" };
static SUNXI_CCU_MUX(cpux_clk, "cpux", cpux_parents,
- 0x050, 16, 2, CLK_IS_CRITICAL);
+ 0x050, 16, 2, CLK_IS_CRITICAL | CLK_SET_RATE_PARENT);
static SUNXI_CCU_M(axi_clk, "axi", "cpux", 0x050, 0, 2, 0);
--
2.10.1
^ permalink raw reply related
* [PATCH 2/2] clk: sunxi-ng: fix up PLL_CPUX adjusting for A23/A33
From: Icenowy Zheng @ 2016-11-06 17:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161106172932.39478-1-icenowy@aosc.xyz>
When adjusting PLL_CPUX on A23/A33, the PLL is driven too high, and the
system stucks.
Add a notifier to avoid this situation.
The code is ported from ccu-sun6i-a31.c.
Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
---
Patch 4.9-rc too.
drivers/clk/sunxi-ng/ccu-sun8i-a23.c | 10 ++++++++++
drivers/clk/sunxi-ng/ccu-sun8i-a33.c | 10 ++++++++++
2 files changed, 20 insertions(+)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a23.c b/drivers/clk/sunxi-ng/ccu-sun8i-a23.c
index 44c4775..41a8594 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-a23.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-a23.c
@@ -709,6 +709,13 @@ static const struct sunxi_ccu_desc sun8i_a23_ccu_desc = {
.num_resets = ARRAY_SIZE(sun8i_a23_ccu_resets),
};
+static struct ccu_mux_nb sun8i_a23_cpu_nb = {
+ .common = &cpux_clk.common,
+ .cm = &cpux_clk.mux,
+ .delay_us = 1, /* > 8 clock cycles at 24 MHz */
+ .bypass_index = 1, /* index of 24 MHz oscillator */
+};
+
static void __init sun8i_a23_ccu_setup(struct device_node *node)
{
void __iomem *reg;
@@ -732,6 +739,9 @@ static void __init sun8i_a23_ccu_setup(struct device_node *node)
writel(val, reg + SUN8I_A23_PLL_MIPI_REG);
sunxi_ccu_probe(node, reg, &sun8i_a23_ccu_desc);
+
+ ccu_mux_notifier_register(pll_cpux_clk.common.hw.clk,
+ &sun8i_a23_cpu_nb);
}
CLK_OF_DECLARE(sun8i_a23_ccu, "allwinner,sun8i-a23-ccu",
sun8i_a23_ccu_setup);
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a33.c b/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
index 59cfdc8..3efbb6e 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
@@ -752,6 +752,13 @@ static const struct sunxi_ccu_desc sun8i_a33_ccu_desc = {
.num_resets = ARRAY_SIZE(sun8i_a33_ccu_resets),
};
+static struct ccu_mux_nb sun8i_a33_cpu_nb = {
+ .common = &cpux_clk.common,
+ .cm = &cpux_clk.mux,
+ .delay_us = 1, /* > 8 clock cycles at 24 MHz */
+ .bypass_index = 1, /* index of 24 MHz oscillator */
+};
+
static void __init sun8i_a33_ccu_setup(struct device_node *node)
{
void __iomem *reg;
@@ -775,6 +782,9 @@ static void __init sun8i_a33_ccu_setup(struct device_node *node)
writel(val, reg + SUN8I_A33_PLL_MIPI_REG);
sunxi_ccu_probe(node, reg, &sun8i_a33_ccu_desc);
+
+ ccu_mux_notifier_register(pll_cpux_clk.common.hw.clk,
+ &sun8i_a33_cpu_nb);
}
CLK_OF_DECLARE(sun8i_a33_ccu, "allwinner,sun8i-a33-ccu",
sun8i_a33_ccu_setup);
--
2.10.1
^ permalink raw reply related
* [linux-sunxi] [PATCH v5 4/7] ASoC: sunxi: Add sun8i I2S driver
From: Jean-Francois Moine @ 2016-11-06 18:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v67gDd650TJk_-oHOehnzdH2qor=36HXdPt339Ji=ToAMg@mail.gmail.com>
On Sun, 23 Oct 2016 09:33:16 +0800
Chen-Yu Tsai <wens@csie.org> wrote:
> On Fri, Oct 21, 2016 at 4:36 PM, Jean-Francois Moine <moinejf@free.fr> wrote:
> > This patch adds I2S support to sun8i SoCs as the A83T and H3.
> >
> > Signed-off-by: Jean-Francois Moine <moinejf@free.fr>
> > ---
> > Note: This driver is closed to the sun4i-i2s except that:
> > - it handles the H3
>
> If it's close to sun4i-i2s, you should probably rework that one to support
> the newer SoCs.
I started to add the H3 into the sun4i-i2s, but I am blocked with
regmap.
Many H3 registers are common with the A10, but some of them have more
or less fields, the fields may be at different offsets. And, finally,
some registers are completely different.
This would not raise any problem, except with regmap which is really
painful.
As I may understood, regmap is used to simplify suspend/resume, but, is
it useful to save the I2S register on suspend?
Practically, I am streaming some tune on my device. I suspend it for
any reason. The next morning, I resume it. Are you sure I want to
continue to hear the end of the tune?
I better think that streaming should be simply stopped on suspend.
Then, there is no need to save the playing registers, and, here I am,
there is no need to use regmap.
May I go this way?
--
Ken ar c'henta? | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
^ permalink raw reply
* [PATCH 2/2] clk: sunxi-ng: fix up PLL_CPUX adjusting for A23/A33
From: Quentin Schulz @ 2016-11-06 18:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161106172932.39478-2-icenowy@aosc.xyz>
Hi Icenowy,
This patch (2/2) should be before the first one.
The first patch allows adjusting of the PLL and the second fixes a
problem with the adjustment of the PLL.
You should fix the problem before allowing the adjustment of the PLL.
That way, if someone builds the kernel between your two patches, the
kernel is supposed to be working.
Tested in correct order on A33.
Thanks!
Quentin
On 06/11/2016 18:29, Icenowy Zheng wrote:
> When adjusting PLL_CPUX on A23/A33, the PLL is driven too high, and the
> system stucks.
>
> Add a notifier to avoid this situation.
>
> The code is ported from ccu-sun6i-a31.c.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> ---
> Patch 4.9-rc too.
> drivers/clk/sunxi-ng/ccu-sun8i-a23.c | 10 ++++++++++
> drivers/clk/sunxi-ng/ccu-sun8i-a33.c | 10 ++++++++++
> 2 files changed, 20 insertions(+)
>
> diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a23.c b/drivers/clk/sunxi-ng/ccu-sun8i-a23.c
> index 44c4775..41a8594 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun8i-a23.c
> +++ b/drivers/clk/sunxi-ng/ccu-sun8i-a23.c
> @@ -709,6 +709,13 @@ static const struct sunxi_ccu_desc sun8i_a23_ccu_desc = {
> .num_resets = ARRAY_SIZE(sun8i_a23_ccu_resets),
> };
>
> +static struct ccu_mux_nb sun8i_a23_cpu_nb = {
> + .common = &cpux_clk.common,
> + .cm = &cpux_clk.mux,
> + .delay_us = 1, /* > 8 clock cycles at 24 MHz */
> + .bypass_index = 1, /* index of 24 MHz oscillator */
> +};
> +
> static void __init sun8i_a23_ccu_setup(struct device_node *node)
> {
> void __iomem *reg;
> @@ -732,6 +739,9 @@ static void __init sun8i_a23_ccu_setup(struct device_node *node)
> writel(val, reg + SUN8I_A23_PLL_MIPI_REG);
>
> sunxi_ccu_probe(node, reg, &sun8i_a23_ccu_desc);
> +
> + ccu_mux_notifier_register(pll_cpux_clk.common.hw.clk,
> + &sun8i_a23_cpu_nb);
> }
> CLK_OF_DECLARE(sun8i_a23_ccu, "allwinner,sun8i-a23-ccu",
> sun8i_a23_ccu_setup);
> diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-a33.c b/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
> index 59cfdc8..3efbb6e 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
> +++ b/drivers/clk/sunxi-ng/ccu-sun8i-a33.c
> @@ -752,6 +752,13 @@ static const struct sunxi_ccu_desc sun8i_a33_ccu_desc = {
> .num_resets = ARRAY_SIZE(sun8i_a33_ccu_resets),
> };
>
> +static struct ccu_mux_nb sun8i_a33_cpu_nb = {
> + .common = &cpux_clk.common,
> + .cm = &cpux_clk.mux,
> + .delay_us = 1, /* > 8 clock cycles at 24 MHz */
> + .bypass_index = 1, /* index of 24 MHz oscillator */
> +};
> +
> static void __init sun8i_a33_ccu_setup(struct device_node *node)
> {
> void __iomem *reg;
> @@ -775,6 +782,9 @@ static void __init sun8i_a33_ccu_setup(struct device_node *node)
> writel(val, reg + SUN8I_A33_PLL_MIPI_REG);
>
> sunxi_ccu_probe(node, reg, &sun8i_a33_ccu_desc);
> +
> + ccu_mux_notifier_register(pll_cpux_clk.common.hw.clk,
> + &sun8i_a33_cpu_nb);
> }
> CLK_OF_DECLARE(sun8i_a33_ccu, "allwinner,sun8i-a33-ccu",
> sun8i_a33_ccu_setup);
>
--
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCH 13/22] mtd: nand: lpc32xx: return error code of nand_scan_ident/tail() on error
From: Boris Brezillon @ 2016-11-06 18:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1478256190-7452-14-git-send-email-yamada.masahiro@socionext.com>
On Fri, 4 Nov 2016 19:43:01 +0900
Masahiro Yamada <yamada.masahiro@socionext.com> wrote:
> The nand_scan_ident/tail() returns an appropriate error value when
> it fails. Use it instead of the fixed error code -ENXIO.
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
>
> drivers/mtd/nand/lpc32xx_mlc.c | 10 ++++------
> drivers/mtd/nand/lpc32xx_slc.c | 9 +++------
> 2 files changed, 7 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/mtd/nand/lpc32xx_mlc.c b/drivers/mtd/nand/lpc32xx_mlc.c
> index 8523881..5553a5d 100644
> --- a/drivers/mtd/nand/lpc32xx_mlc.c
> +++ b/drivers/mtd/nand/lpc32xx_mlc.c
> @@ -747,10 +747,9 @@ static int lpc32xx_nand_probe(struct platform_device *pdev)
> * Scan to find existance of the device and
> * Get the type of NAND device SMALL block or LARGE block
> */
> - if (nand_scan_ident(mtd, 1, NULL)) {
> - res = -ENXIO;
> + res = nand_scan_ident(mtd, 1, NULL);
> + if (res)
> goto err_exit3;
> - }
>
> host->dma_buf = devm_kzalloc(&pdev->dev, mtd->writesize, GFP_KERNEL);
> if (!host->dma_buf) {
> @@ -793,10 +792,9 @@ static int lpc32xx_nand_probe(struct platform_device *pdev)
> * Fills out all the uninitialized function pointers with the defaults
> * And scans for a bad block table if appropriate.
> */
> - if (nand_scan_tail(mtd)) {
> - res = -ENXIO;
> + res = nand_scan_tail(mtd);
> + if (res)
> goto err_exit4;
> - }
>
> mtd->name = DRV_NAME;
>
> diff --git a/drivers/mtd/nand/lpc32xx_slc.c b/drivers/mtd/nand/lpc32xx_slc.c
> index 8d3edc3..f1094e5 100644
> --- a/drivers/mtd/nand/lpc32xx_slc.c
> +++ b/drivers/mtd/nand/lpc32xx_slc.c
> @@ -894,10 +894,9 @@ static int lpc32xx_nand_probe(struct platform_device *pdev)
> }
>
> /* Find NAND device */
> - if (nand_scan_ident(mtd, 1, NULL)) {
> - res = -ENXIO;
> + res = nand_scan_ident(mtd, 1, NULL);
> + if (res)
> goto err_exit3;
> - }
>
> /* OOB and ECC CPU and DMA work areas */
> host->ecc_buf = (uint32_t *)(host->data_buf + LPC32XX_DMA_DATA_SIZE);
> @@ -929,10 +928,8 @@ static int lpc32xx_nand_probe(struct platform_device *pdev)
> /*
> * Fills out all the uninitialized function pointers with the defaults
> */
> - if (nand_scan_tail(mtd)) {
> - res = -ENXIO;
> + res = nand_scan_tail(mtd);
You miss
if (res)
here.
No need to resend, I'll fix it when applying the patches.
> goto err_exit3;
> - }
>
> mtd->name = "nxp_lpc3220_slc";
> res = mtd_device_register(mtd, host->ncfg->parts,
^ permalink raw reply
* [Bug] ARM: mxs: STI: console can't wake up from freeze
From: Stefan Wahren @ 2016-11-06 18:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <f03db663-908e-e416-ad50-bdb5cbf6c2c9@linaro.org>
> Daniel Lezcano <daniel.lezcano@linaro.org> hat am 6. November 2016 um 15:55
> geschrieben:
>
>
> On 06/11/2016 11:20, Stefan Wahren wrote:
> > Hi,
> >
> >> Russell King - ARM Linux <linux@armlinux.org.uk> hat am 5. November 2016 um
> >> 19:05 geschrieben:
> >>
> >>
> >> On Sat, Nov 05, 2016 at 04:28:37PM +0100, Stefan Wahren wrote:
> >>> As i wrote in my email before, i added a pr_info() into freeze_wake.
> >>> But i never see the output of this message. So i assume freeze_wake
> >>> is never called. Again, how could this happen?
> >>
> >> Hmm, so the bit that you're getting stuck on is:
> >>
> >> wait_event(suspend_freeze_wait_head,
> >> suspend_freeze_state == FREEZE_STATE_WAKE);
> >>
> >
> > thanks for all the feedback. The real cause for this issue is in the irqchip
> > driver. I fixed it with this patch:
>
> Mind to give some details ?
>
No. AFAIK the serial_core already handles the suspend to idle. But it requires
that enable_irq_wake for the UART IRQ succeed. Unfortunately the irq-mxs (like a
couple of other irqchip drivers) neither implemented set_irq_wake or set
IRQCHIP_SKIP_SET_WAKE so enable_irq_wake will fail with -ENXIO and the UART
won't be setup as wakeup source. As the mxs interrupt controller doesn't provide
any facility to setup wakeup source i choose to use IRQCHIP_SKIP_SET_WAKE.
Instead of failing silently it would be better if sysfs won't allow to enable
wakeup source in this case or at least the serial core should complains about
it.
^ permalink raw reply
* [PATCH v2 2/9] drm/sun4i: support A33 tcon
From: Maxime Ripard @ 2016-11-06 18:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v66q_07frb2k_A8mpeXT1SX3VdtNc5JbfR1hcK29iCXfQg@mail.gmail.com>
On Sat, Nov 05, 2016 at 11:54:28PM +0800, Chen-Yu Tsai wrote:
> Hi,
>
> On Tue, Sep 6, 2016 at 10:46 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > The A33 has a significantly different pipeline, with components that differ
> > too.
> >
> > Make sure we had compatible for them.
> >
> > Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> > ---
> > Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 7 ++++++-
> > drivers/gpu/drm/sun4i/sun4i_backend.c | 1 +
> > drivers/gpu/drm/sun4i/sun4i_drv.c | 8 +++++---
> > drivers/gpu/drm/sun4i/sun4i_tcon.c | 8 +++++++-
> > 4 files changed, 19 insertions(+), 5 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > index df8f4aeefe4c..bd3136a5cba5 100644
> > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt
> > @@ -26,7 +26,9 @@ TCON
> > The TCON acts as a timing controller for RGB, LVDS and TV interfaces.
> >
> > Required properties:
> > - - compatible: value should be "allwinner,sun5i-a13-tcon".
> > + - compatible: value must be either:
> > + * allwinner,sun5i-a13-tcon
> > + * allwinner,sun8i-a33-tcon
> > - reg: base address and size of memory-mapped region
> > - interrupts: interrupt associated to this IP
> > - clocks: phandles to the clocks feeding the TCON. Three are needed:
> > @@ -59,6 +61,7 @@ system.
> > Required properties:
> > - compatible: value must be one of:
> > * allwinner,sun5i-a13-display-backend
> > + * allwinner,sun8i-a33-display-backend
> > - reg: base address and size of the memory-mapped region.
> > - clocks: phandles to the clocks feeding the frontend and backend
> > * ahb: the backend interface clock
> > @@ -80,6 +83,7 @@ deinterlacing and color space conversion.
> > Required properties:
> > - compatible: value must be one of:
> > * allwinner,sun5i-a13-display-frontend
> > + * allwinner,sun8i-a33-display-frontend
>
> I just looked at the A23. It seems it's the same display frontend as the A33.
> Should we change the compatible string to a23 while it's still in RC?
>
> The backend is probably different. The A33 only claims to support 2048x2048
> layers, while the A23 claims to support 8192x8192 layers.
I think we can still keep it. Especially if we're not sure, we might
need to make use of it in the future.
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: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161106/3920c312/attachment.sig>
^ permalink raw reply
* [PATCH 2/2] arm64: dts: sunxi: enable EHCI1, OHCI1 and USB PHY nodes in Pine64
From: Maxime Ripard @ 2016-11-06 18:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161105143830.10099-2-icenowy@aosc.xyz>
Hi,
On Sat, Nov 05, 2016 at 10:38:30PM +0800, Icenowy Zheng wrote:
> Pine64 have two USB Type-A ports, which are wired to the two ports of
> A64 USB PHY, and the lower port is the EHCI/OHCI1 port.
>
> Enable the necessary nodes to enable the lower USB port to work.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> ---
> arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> index 4709590..d836995 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
> @@ -72,3 +72,15 @@
> &i2c1_pins {
> bias-pull-up;
> };
> +
> +&usbphy {
> + status = "okay";
> +};
> +
> +&ehci1 {
> + status = "okay";
> +};
> +
> +&ohci1 {
> + status = "okay";
> +};
Please order the nodes by alphebetical order.
Thanks!
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: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161106/7ed96284/attachment.sig>
^ permalink raw reply
* [PATCH 1/2] arm64: dts: add USB1-related nodes of Allwinner A64
From: Maxime Ripard @ 2016-11-06 18:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161105143830.10099-1-icenowy@aosc.xyz>
On Sat, Nov 05, 2016 at 10:38:29PM +0800, Icenowy Zheng wrote:
> Allwinner A64 have two HCI USB controllers, a OTG controller and a USB
> PHY device which have two ports. One of the port is wired to both a HCI
> USB controller and the OTG controller, which is currently not supported.
> The another one is only wired to a HCI controller, and the device node of
> OHCI/EHCI controller of the port can be added now.
>
> Also the A64 USB PHY device node is also added for the HCI controllers to
> work.
>
> Signed-off-by: Icenowy Zheng <icenowy@aosc.xyz>
> ---
> arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 50 +++++++++++++++++++++++++++
> 1 file changed, 50 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index 3d70be3..c2b6dc8 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -259,5 +259,55 @@
> interrupts = <GIC_SPI 40 IRQ_TYPE_LEVEL_HIGH>,
> <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>;
> };
> +
> + usbphy: phy at 01c19400 {
> + compatible = "allwinner,sun50i-a64-usb-phy";
> + reg = <0x01c19400 0x14>,
> + <0x01c1b800 0x4>;
> + reg-names = "phy_ctrl",
> + "pmu1";
> + clocks = <&ccu CLK_USB_PHY0>,
> + <&ccu CLK_USB_PHY1>;
> + clock-names = "usb0_phy",
> + "usb1_phy";
> + resets = <&ccu RST_USB_PHY0>,
> + <&ccu RST_USB_PHY1>;
> + reset-names = "usb0_reset",
> + "usb1_reset";
> + status = "disabled";
> + #phy-cells = <1>;
> + };
> +
> + ohci1: usb at 01c1a400 {
> + compatible = "allwinner,sun50i-a64-ohci", "generic-ohci";
> + reg = <0x01c1b400 0x100>;
> + interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
> + /*
> + * According to the user manual, OHCI1 USB clock
> + * depends on OHCI0 clock.
> + */
This is something that should be dealt with in the clock framework,
not in your driver.
> + clocks = <&ccu CLK_BUS_OHCI1>,
> + <&ccu CLK_USB_OHCI0>,
> + <&ccu CLK_USB_OHCI1>;
> + resets = <&ccu RST_BUS_OHCI1>;
> + phys = <&usbphy 1>;
> + phy-names = "usb";
> + status = "disabled";
> + };
> +
> + ehci1: usb at 01c1a000 {
> + compatible = "allwinner,sun50i-a64-ehci", "generic-ehci";
> + reg = <0x01c1b000 0x100>;
And please order these nodes by base address.
Also, in both the ehci and ohci nodes, the unit-address and reg don't
match, which one is the right one?
Thanks,
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: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161106/8451990e/attachment.sig>
^ permalink raw reply
* [PATCH v2 06/14] ASoC: sun4i-codec: Add support for A31 playback through headphone output
From: Maxime Ripard @ 2016-11-06 18:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGb2v65CZJ+1LTWWk3+vABV8PDgsDta+nZ7o3H2Z--KFPe2kog@mail.gmail.com>
On Fri, Nov 04, 2016 at 09:08:11AM +0800, Chen-Yu Tsai wrote:
> On Fri, Nov 4, 2016 at 1:36 AM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > Hi,
> >
> > On Thu, Nov 03, 2016 at 03:55:48PM +0800, Chen-Yu Tsai wrote:
> >> +/* headphone controls */
> >> +static const char * const sun6i_codec_hp_src_enum_text[] = {
> >> + "DAC", "Mixer",
> >> +};
> >> +
> >> +static SOC_ENUM_DOUBLE_DECL(sun6i_codec_hp_src_enum,
> >> + SUN6I_CODEC_OM_DACA_CTRL,
> >> + SUN6I_CODEC_OM_DACA_CTRL_LHPIS,
> >> + SUN6I_CODEC_OM_DACA_CTRL_RHPIS,
> >> + sun6i_codec_hp_src_enum_text);
> >> +
> >> +static const struct snd_kcontrol_new sun6i_codec_hp_src[] = {
> >> + SOC_DAPM_ENUM("Headphone Source Playback Route",
> >> + sun6i_codec_hp_src_enum),
> >> +};
> >
> > What is that route exactly? A muxer?
>
> Yup. The following is part of the widgets list later in the code:
>
> + /* Headphone output path */
> + SND_SOC_DAPM_MUX("Headphone Source Playback Route",
> + SND_SOC_NOPM, 0, 0, sun6i_codec_hp_src),
Oh, right.
You can add my Acked-by on this one and the other patches too.
Thanks!
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: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161106/37df34b8/attachment-0001.sig>
^ permalink raw reply
* [PATCH] ARM64: dts: amlogic: Reorder copyrights for meson-gx
From: Andreas Färber @ 2016-11-06 19:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1475595430-30075-2-git-send-email-narmstrong@baylibre.com>
meson-gx.dtsi was directly derived from meson-gxbb.dtsi, so keep the
copyrights in chronological order to not give a wrong impression.
Fixes: c328666d58aa ("ARM64: dts: amlogic: Add Meson GX dtsi from GXBB")
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Andreas F?rber <afaerber@suse.de>
---
arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
index fd1d0deef889..0b57d037974c 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gx.dtsi
@@ -1,12 +1,12 @@
/*
+ * Copyright (c) 2016 Andreas F?rber
+ *
* Copyright (c) 2016 BayLibre, SAS.
* Author: Neil Armstrong <narmstrong@baylibre.com>
*
* Copyright (c) 2016 Endless Computers, Inc.
* Author: Carlo Caione <carlo@endlessm.com>
*
- * Copyright (c) 2016 Andreas F?rber
- *
* This file is dual-licensed: you can use it either under the terms
* of the GPL or the X11 license, at your option. Note that this dual
* licensing only applies to this file, and not this project as a
--
2.6.6
^ permalink raw reply related
* [PATCH RFC] ARM: dts: add support for Turris Omnia
From: Uwe Kleine-König @ 2016-11-06 19:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161106162809.GA14042@lunn.ch>
Hello,
I just noticed that I dropped the other recipents from the conversation.
I readded them also adding some context.
> > On Sun, Nov 06, 2016 at 05:28:09PM +0100, Andrew Lunn wrote:
> > > On Sun, Nov 06, 2016 at 11:45:34AM +0100, Uwe Kleine-K?nig wrote:
> > > > + switch at 0 {
> > > > + compatible = "marvell,mv88e6176", "marvell,mv88e6085";
> > >
> > > All currently supported switches are compatible with the mv88e6085, in
> > > terms of probing. During the probe it can read an ID register to find
> > > out what specific switch it is, so you don't need additional details
> > > here. So please drop the marvell,mv88e6176, it will never be used.
> >
> > That's what I know from several imx devices, for example look at
> >
> > $ git grep imx25 arch/arm/boot/dts/imx25.dtsi
> >
> > There are several instances of imx25-something,
> > imx$earliersoc-something. Given there is a good reason for this, I
> > wonder why it's different here.
>
> Possibly because you cannot easily tell the variants apart using ID
> registers in the devices register space? For the switch it is very
> easy, port register 3 is the ID. It only becomes an issue when probe
> cannot find this register. There is a new generation mv88e6390 which
> i'm currently adding support for which has moved the port
> registers. So i need to add a new compatible string so probe knows
> where to look.
Even if you cannot easily distinguish between an "fsl,imx35-cspi" and an
"fsl,imx27-cspi" by inspecting hardware registers, it would be enough to
write in imx25.dtsi
compatible = "fsl,imx35-cspi";
still we're writing
compatible = "fsl,imx25-cspi", "fsl,imx35-cspi";
because it never hurts and is helpful when later some differences are
found and it documents the situation more accurately.
I wonder what the dt people have to say here.
> > > From what you say here, the switch is in mulit-chip mode, at address
> > > 0x10. So set the reg property to <0x10>.
> >
> > When using 0x10 I get
> >
> > mv88e6085 f1072004.mdio-mi:10: switch 0x176 probed: Marvell 88E6176, revision 1
>
> Great.
>
> >
> > so now I have to find out how to use this.
>
> Just use them as normal interfaces. ip addr add 10.42.42.42/24 dev
> lan4, brctrl addif br0 lan2, ethtool -S lan1 etc.
>
> The whole idea is that they are just normal Linux network interfaces.
That's how I expected things to be, but
uwe at omnia:~$ dmesg | tail
...
[ 2164.644589] libphy: mdio_driver_register: mv88e6085
[ 2164.649823] mv88e6085 f1072004.mdio-mi:10: switch 0x176 probed: Marvell 88E6176, revision 1
uwe at omnia:~$ ls /sys/class/net/
eth0 eth1 eth2 lo
there are no additional interfaces. I will debug a bit further.
Best regards
Uwe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161106/854a7843/attachment.sig>
^ 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