Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v7 5/5] ARM: dts: imx6qdl-icore: Add FEC support
From: Shawn Guo @ 2016-10-21  1:31 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1476437243-13297-6-git-send-email-jteki@openedev.com>

On Fri, Oct 14, 2016 at 02:57:23PM +0530, Jagan Teki wrote:
> From: Jagan Teki <jagan@amarulasolutions.com>
> 
> Add FEC support for Engicam i.CoreM6 dql modules.
> 
> Observed similar 'eth0: link is not ready' issue which was
> discussed in [1] due rmii mode with external ref_clk, so added
> clock node along with the properties mentioned by Shawn in [2]
> 
> FEC link log:
> ------------
> $ ifconfig eth0 up
> [   27.905187] SMSC LAN8710/LAN8720 2188000.ethernet:00: attached PHY driver
>                [SMSC LAN8710/LAN8720] (mii_bus:phy_addr=2188000.ethernet:00, irq=-1)
> [   27.918982] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> 
> [1] https://patchwork.kernel.org/patch/3491061/
> [2] https://patchwork.kernel.org/patch/3490511/
> 
> Cc: Sascha Hauer <kernel@pengutronix.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
> Cc: Matteo Lisi <matteo.lisi@engicam.com>
> Cc: Michael Trimarchi <michael@amarulasolutions.com>
> Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
> ---
> Changes for v7:
>         - none
> Changes for v6:
>         - none
> Changes for v5:
>         - new patch
> 
>  arch/arm/boot/dts/imx6qdl-icore.dtsi | 37 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 37 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx6qdl-icore.dtsi b/arch/arm/boot/dts/imx6qdl-icore.dtsi
> index 4e79858..972f48f 100644
> --- a/arch/arm/boot/dts/imx6qdl-icore.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-icore.dtsi
> @@ -48,6 +48,18 @@
>  		reg = <0x10000000 0x80000000>;
>  	};
>  
> +	clocks {
> +		#address-cells = <1>;
> +		#size-cells = <0>;

DT maintainers do not like this container node.  So please, just like
fix regulator node, put the fixed clock directly under root and give the
node an unique name like clock-xxx.

> +
> +		rmii_clk: clock at 0 {
> +			compatible = "fixed-clock";
> +			reg = <0>;
> +			#clock-cells = <0>;
> +			clock-frequency = <25000000>;  /* 25MHz for example */
> +		};
> +	};
> +
>  	reg_3p3v: regulator-3p3v {
>  		compatible = "regulator-fixed";
>  		regulator-name = "3P3V";
> @@ -93,6 +105,15 @@
>  	assigned-clock-parents = <&clks IMX6QDL_CLK_OSC>;
>  };
>  
> +&fec {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&pinctrl_enet>;
> +	phy-reset-gpios = <&gpio7 12 GPIO_ACTIVE_LOW>;
> +	clocks = <&clks 117>, <&clks 117>, <&rmii_clk>;

s/117/IMX6QDL_CLK_ENET

Shawn

> +	phy-mode = "rmii";
> +	status = "okay";
> +};
> +
>  &gpmi {
>  	pinctrl-names = "default";
>  	pinctrl-0 = <&pinctrl_gpmi_nand>;
> @@ -150,6 +171,22 @@
>  };
>  
>  &iomuxc {
> +	pinctrl_enet: enetgrp {
> +		fsl,pins = <
> +			MX6QDL_PAD_ENET_CRS_DV__ENET_RX_EN	0x1b0b0
> +			MX6QDL_PAD_GPIO_16__ENET_REF_CLK	0x1b0b1
> +			MX6QDL_PAD_ENET_TX_EN__ENET_TX_EN	0x1b0b0
> +			MX6QDL_PAD_ENET_RXD1__ENET_RX_DATA1	0x1b0b0
> +			MX6QDL_PAD_ENET_RXD0__ENET_RX_DATA0	0x1b0b0
> +			MX6QDL_PAD_ENET_TXD1__ENET_TX_DATA1	0x1b0b0
> +			MX6QDL_PAD_ENET_TXD0__ENET_TX_DATA0	0x1b0b0
> +			MX6QDL_PAD_ENET_MDC__ENET_MDC		0x1b0b0
> +			MX6QDL_PAD_ENET_MDIO__ENET_MDIO		0x1b0b0
> +			MX6QDL_PAD_ENET_REF_CLK__GPIO1_IO23	0x1b0b0
> +			MX6QDL_PAD_GPIO_17__GPIO7_IO12		0x1b0b0
> +		>;
> +	};
> +
>  	pinctrl_flexcan1: flexcan1grp {
>  		fsl,pins = <
>  			MX6QDL_PAD_KEY_ROW2__FLEXCAN1_RX 0x1b020
> -- 
> 2.7.4
> 

^ permalink raw reply

* [PATCH v3 0/8] PM / Domains: DT support for domain idle states & atomic PM domains
From: Lina Iyer @ 2016-10-21  1:33 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAJZ5v0iKuSWr8xVha7HZ764z+Xk_urP1XFVV-VZ5+JQTuSj-bw@mail.gmail.com>

On Fri, Oct 21 2016 at 16:48 -0600, Rafael J. Wysocki wrote:
>On Fri, Oct 21, 2016 at 12:44 AM, Lina Iyer <lina.iyer@linaro.org> wrote:
>> On Mon, Oct 17 2016 at 01:30 -0600, Ulf Hansson wrote:
>>>
>>> On 14 October 2016 at 19:47, Lina Iyer <lina.iyer@linaro.org> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> Changes since v2 [3] -
>>>> - Addressed review comments from v2.
>>>>         - domain-idle-states documentation updated
>>>>         - fixed compiler issues with imx driver
>>>>         - minor code change in pm_domains.c
>>>> - The series is available at [4].
>>>>
>>>> Changes since v1 [2] -
>>>> - Addressed review comments from v1.
>>>>         - Fixes around dynamic allocation of genpd states
>>>>         - Used OF method for iterating phandles
>>>>         - Updated documentation, examples
>>>>         - Rename state variable (provider -> fwnode)
>>>> - The series is available at [3].
>>>>
>>>> The changes from [1] are -
>>>> - Allocating memory for domain idle states dynamically
>>>> - Conform to naming conventions for internal and exported genpd functions
>>>> - DT binding example for domain-idle-state
>>>> - Use fwnode instead of of_node
>>>> - Handle atomic case for removal of PM Domain
>>>> - Rebase on top of Rafael's pm/genpd tree
>>>>
>>>> Thanks,
>>>> Lina
>>>>
>>>> Lina Iyer (8):
>>>>   PM / Domains: Make genpd state allocation dynamic
>>>>   PM / Domain: Add residency property to genpd states
>>>>   PM / Domains: Allow domain power states to be read from DT
>>>>   PM / Domains: Save the fwnode in genpd_power_state
>>>>   dt/bindings: Update binding for PM domain idle states
>>>>   PM / Domains: Abstract genpd locking
>>>>   PM / Domains: Support IRQ safe PM domains
>>>>   PM / doc: Update device documentation for devices in IRQ safe PM
>>>>     domains
>>>>
>>>>  .../devicetree/bindings/power/power_domain.txt     |  43 +++
>>>>  Documentation/power/devices.txt                    |   9 +-
>>>>  arch/arm/mach-imx/gpc.c                            |  17 +-
>>>>  drivers/base/power/domain.c                        | 358
>>>> +++++++++++++++++----
>>>>  include/linux/pm_domain.h                          |  28 +-
>>>>  5 files changed, 383 insertions(+), 72 deletions(-)
>>>>
>>>
>>> Rafael, Lina,
>>>
>>> This looks good to me! Unless any other objections, I suggest to apply
>>> this to get it tested in linux-next.
>>>
>>> Kind regards
>>> Uffe
>>>
>> Rafael,
>>
>> If there are no objections, could you pick this patch for linux-next?
>
>It is in my queue, but not at the top yet.
>
Thank you Rafael.

-- Lina

>Thanks,
>Rafael

^ permalink raw reply

* [PATCH v7 0/5] ARM: dts: imx6q: Add Engicam i.CoreM6 dts
From: Shawn Guo @ 2016-10-21  1:35 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAD6G_RQyLtgJw=djPTmY5t7UVwzuZpj0xM0HjchLQjq7P5hMOg@mail.gmail.com>

On Tue, Oct 18, 2016 at 05:30:28PM +0530, Jagan Teki wrote:
> Hi Shawn,
> 
> On Fri, Oct 14, 2016 at 2:57 PM, Jagan Teki <jteki@openedev.com> wrote:
> > This is series add dts support for Engicam I.Core M6 qdl modules. just
> > rebased on top of linux-next of previous set[1].
> >
> > [1] http://www.spinics.net/lists/kernel/msg2358233.html
> >
> > Jagan Teki (5):
> >   ARM: dts: imx6q: Add Engicam i.CoreM6 Quad/Dual initial support
> >   ARM: dts: imx6q: Add Engicam i.CoreM6 DualLite/Solo initial support
> >   ARM: dts: imx6qdl-icore: Add usbhost support
> >   ARM: dts: imx6qdl-icore: Add usbotg support
> >   ARM: dts: imx6qdl-icore: Add FEC support
> >
> >  arch/arm/boot/dts/Makefile           |   2 +
> >  arch/arm/boot/dts/imx6dl-icore.dts   |  59 ++++++++
> >  arch/arm/boot/dts/imx6q-icore.dts    |  59 ++++++++
> >  arch/arm/boot/dts/imx6qdl-icore.dtsi | 271 +++++++++++++++++++++++++++++++++++
> >  4 files changed, 391 insertions(+)
> >  create mode 100644 arch/arm/boot/dts/imx6dl-icore.dts
> >  create mode 100644 arch/arm/boot/dts/imx6q-icore.dts
> >  create mode 100644 arch/arm/boot/dts/imx6qdl-icore.dtsi
> 
> Can you pick this series?

Sorry for the delay.  The first two patches look good, and I had a
couple of small comments on the other 3.  Also, for the initial board
support submission like this, you do not need to split it per device
support.  That said, please squash the series into one patch when
resending.

Shawn

^ permalink raw reply

* [PATCH V4 1/3] ACPI, PCI, IRQ: assign ISA IRQ directly during early boot stages
From: Bjorn Helgaas @ 2016-10-21  1:39 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1476915664-27231-2-git-send-email-okaya@codeaurora.org>

On Wed, Oct 19, 2016 at 06:21:02PM -0400, Sinan Kaya wrote:
> The penalty determination of ISA IRQ goes through 4 paths.
> 1. assign PCI_USING during power up via acpi_irq_penalty_init.
> 2. update the penalty with acpi_penalize_isa_irq function based on the
> active parameter.
> 3. kernel command line penalty update via acpi_irq_penalty_update function.
> 4. increment the penalty as USING right after the IRQ is assign to PCI.
> 
> acpi_penalize_isa_irq and acpi_irq_penalty_update functions get called
> before the ACPI subsystem is started.
> 
> These API need to bypass the acpi_irq_get_penalty function.

I don't mind this patch, but the changelog doesn't tell me what's
broken and why we need this fix.  Apparently acpi_irq_get_penalty()
doesn't work before ACPI is initialized, but I don't see *why* it
wouldn't work.

However, I see one bug it *does* fix: we do not store the SCI penalty
in the acpi_isa_irq_penalty[] table because acpi_isa_irq_penalty[]
only holds ISA IRQ penalties, and there's no guarantee that the SCI is
an ISA IRQ.  But prior to this patch, we added in the SCI penalty to
the acpi_isa_irq_penalty[] entry when the SCI was an ISA IRQ, which
makes acpi_irq_get_penalty() return the wrong thing.  Consider:

  Initially     acpi_isa_irq_penalty[9] = 0.
  Assume        sci_interrupt = 9.
  Then          acpi_irq_get_penalty(9) returns X.
  If we call    acpi_penalize_isa_irq(9, 1),
  it sets       acpi_isa_irq_penalty[9] = X,
  and now       acpi_irq_get_penalty(9) returns X + X.

I'd propose a changelog like this:

  We do not want to store the SCI penalty in the acpi_isa_irq_penalty[]
  table because acpi_isa_irq_penalty[] only holds ISA IRQ penalties and
  there's no guarantee that the SCI is an ISA IRQ.  We add in the SCI
  penalty as a special case in acpi_irq_get_penalty().

  But if we called acpi_penalize_isa_irq() or acpi_irq_penalty_update()
  for an SCI that happened to be an ISA IRQ, they stored the SCI
  penalty (part of the acpi_irq_get_penalty() return value) in
  acpi_isa_irq_penalty[].  Subsequent calls to acpi_irq_get_penalty()
  returned a penalty that included *two* SCI penalties.

If this actually fixes a worse problem related to ACPI initialization,
of course you should detail that.

Acked-by: Bjorn Helgaas <bhelgaas@google.com>

> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
>  drivers/acpi/pci_link.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index c983bf7..4f37938 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -849,7 +849,7 @@ static int __init acpi_irq_penalty_update(char *str, int used)
>  			continue;
>  
>  		if (used)
> -			new_penalty = acpi_irq_get_penalty(irq) +
> +			new_penalty = acpi_isa_irq_penalty[irq] +
>  					PIRQ_PENALTY_ISA_USED;
>  		else
>  			new_penalty = 0;
> @@ -871,7 +871,7 @@ static int __init acpi_irq_penalty_update(char *str, int used)
>  void acpi_penalize_isa_irq(int irq, int active)
>  {
>  	if ((irq >= 0) && (irq < ARRAY_SIZE(acpi_isa_irq_penalty)))
> -		acpi_isa_irq_penalty[irq] = acpi_irq_get_penalty(irq) +
> +		acpi_isa_irq_penalty[irq] = acpi_isa_irq_penalty[irq] +
>  		  (active ? PIRQ_PENALTY_ISA_USED : PIRQ_PENALTY_PCI_USING);
>  }
>  
> -- 
> 1.9.1
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH 2/3] clk: hisilicon: add CRG driver for Hi3516CV300 SoC
From: Jiancheng Xue @ 2016-10-21  1:46 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161020174805.GA26139@codeaurora.org>



? 2016/10/21 1:48, Stephen Boyd ??:
> On 10/19, Jiancheng Xue wrote:
>>
>> I'm pretty sure that the patch was sent to the DT list devicetree at vger.kernel.org.
>> You had asked a question about "hi3798cv200-sysctrl" and I replied (https://lkml.org/lkml/2016/10/10/517).
>> I'm waiting for your new comments. If there's some misunderstatnding, please let me know.
>>
> 
> Are there two patch series that touch the same clk binding
> document?  Can you please combine them and resend them if that's
> the case?
> 

OK. I will resend this patch.

Thanks,
Jiancheng

^ permalink raw reply

* [PATCH V4 2/3] Revert "ACPI,PCI,IRQ: remove SCI penalize function"
From: Bjorn Helgaas @ 2016-10-21  1:58 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1476915664-27231-3-git-send-email-okaya@codeaurora.org>

On Wed, Oct 19, 2016 at 06:21:03PM -0400, Sinan Kaya wrote:
> The SCI penalize function was removed in two steps (first refactor
> and then remove) and these changes are reverted here in one go.
> 
> The commit 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements")
> refactored the original code so that SCI penalty is calculated dynamically
> by the time get_penalty function is called. That change is partially
> reverted here, specifically for the SCI IRQ alone.
> 
> The SCI penalize function was finally dropped by commit 9e5ed6d1fb87
> ("ACPI,PCI,IRQ: remove SCI penalize function") that replaced the old SCI
> penalty API with penalty calculation carried out dynamically and based
> on the acpi_gbl_FADT.sci_interrupt value.
> 
> However, that new algorithm relies on the accurate setting of IRQ
> types and that doesn't happen early enough on some platforms which
> leads to incorrect penalty assignments for PCI IRQs.  In those cases,
> irq_get_trigger_type() returns incorrect values for the IRQs in
> question, because they have not been registered yet by the time the
> penalties are calculated.
> 
> To fix this problem, we only need to fix the penalty for the SCI interrupt.
> It seems better to add a single "sci_penalty" variable, set it to
> PIRQ_PENALTY_PCI_USING if it's level/low or PIRQ_PENALTY_ISA_ALWAYS
> otherwise, and add "sci_penalty" in when appropriate.  That should fix it
> for *any* SCI IRQ, not just those less than 256, and we don't have to add
> these extra penalty table entries that are all unused (except possibly for
> one entry if we have an SCI in the 16-255 range).
> 
> For this reason, revert commit 9e5ed6d1fb87 ("ACPI,PCI,IRQ: remove SCI
> penalize function") completely to restore the correct behavior.

I like this patch fine, except for the changelog.  I don't think it's
useful to describe this as a revert and give all the historical
details.  I think the important part is something like this:

  We previously used irq_get_trigger_type(irq) to help compute the
  penalty for the SCI, but that depends on the SCI having been
  registered already.  Add acpi_penalize_sci_irq() so platforms can
  tell us the SCI IRQ, trigger, and polarity so we can compute the
  penalty even before the SCI has been registered.

Acked-by: Bjorn Helgaas <bhelgaas@google.com>

> Link: https://lkml.org/lkml/2016/10/4/283
> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> Fixes: commit 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements")
> Fixes: commit 9e5ed6d1fb87 ("ACPI,PCI,IRQ: remove SCI penalize function")

"commit" is redundant; it's sufficient to say:

  Fixes: 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements")

In fact, I don't think you really need to include "commit" in the
reference to 9e5ed6d1fb87 above either.

> ---
>  arch/x86/kernel/acpi/boot.c |  1 +
>  drivers/acpi/pci_link.c     | 30 +++++++++++++++---------------
>  include/linux/acpi.h        |  1 +
>  3 files changed, 17 insertions(+), 15 deletions(-)
> 
> diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
> index 90d84c3..0ffd26e 100644
> --- a/arch/x86/kernel/acpi/boot.c
> +++ b/arch/x86/kernel/acpi/boot.c
> @@ -453,6 +453,7 @@ static void __init acpi_sci_ioapic_setup(u8 bus_irq, u16 polarity, u16 trigger,
>  		polarity = acpi_sci_flags & ACPI_MADT_POLARITY_MASK;
>  
>  	mp_override_legacy_irq(bus_irq, polarity, trigger, gsi);
> +	acpi_penalize_sci_irq(bus_irq, trigger, polarity);
>  
>  	/*
>  	 * stash over-ride to indicate we've been here
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index 4f37938..294b190 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -87,6 +87,7 @@ struct acpi_pci_link {
>  
>  static LIST_HEAD(acpi_link_list);
>  static DEFINE_MUTEX(acpi_link_lock);
> +static int sci_irq = -1, sci_penalty;
>  
>  /* --------------------------------------------------------------------------
>                              PCI Link Device Management
> @@ -496,25 +497,13 @@ static int acpi_irq_get_penalty(int irq)
>  {
>  	int penalty = 0;
>  
> -	/*
> -	* Penalize IRQ used by ACPI SCI. If ACPI SCI pin attributes conflict
> -	* with PCI IRQ attributes, mark ACPI SCI as ISA_ALWAYS so it won't be
> -	* use for PCI IRQs.
> -	*/
> -	if (irq == acpi_gbl_FADT.sci_interrupt) {
> -		u32 type = irq_get_trigger_type(irq) & IRQ_TYPE_SENSE_MASK;
> -
> -		if (type != IRQ_TYPE_LEVEL_LOW)
> -			penalty += PIRQ_PENALTY_ISA_ALWAYS;
> -		else
> -			penalty += PIRQ_PENALTY_PCI_USING;
> -	}
> +	if (irq == sci_irq)
> +		penalty += sci_penalty;
>  
>  	if (irq < ACPI_MAX_ISA_IRQS)
>  		return penalty + acpi_isa_irq_penalty[irq];
>  
> -	penalty += acpi_irq_pci_sharing_penalty(irq);
> -	return penalty;
> +	return penalty + acpi_irq_pci_sharing_penalty(irq);
>  }
>  
>  int __init acpi_irq_penalty_init(void)
> @@ -881,6 +870,17 @@ bool acpi_isa_irq_available(int irq)
>  		    acpi_irq_get_penalty(irq) < PIRQ_PENALTY_ISA_ALWAYS);
>  }
>  
> +void acpi_penalize_sci_irq(int irq, int trigger, int polarity)
> +{
> +	sci_irq = irq;
> +
> +	if (trigger == ACPI_MADT_TRIGGER_LEVEL &&
> +	    polarity == ACPI_MADT_POLARITY_ACTIVE_LOW)
> +		sci_penalty = PIRQ_PENALTY_PCI_USING;
> +	else
> +		sci_penalty = PIRQ_PENALTY_ISA_ALWAYS;
> +}
> +
>  /*
>   * Over-ride default table to reserve additional IRQs for use by ISA
>   * e.g. acpi_irq_isa=5
> diff --git a/include/linux/acpi.h b/include/linux/acpi.h
> index c5eaf2f..67d1d3e 100644
> --- a/include/linux/acpi.h
> +++ b/include/linux/acpi.h
> @@ -318,6 +318,7 @@ struct pci_dev;
>  int acpi_pci_irq_enable (struct pci_dev *dev);
>  void acpi_penalize_isa_irq(int irq, int active);
>  bool acpi_isa_irq_available(int irq);
> +void acpi_penalize_sci_irq(int irq, int trigger, int polarity);
>  void acpi_pci_irq_disable (struct pci_dev *dev);
>  
>  extern int ec_read(u8 addr, u8 *val);
> -- 
> 1.9.1
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH v5 11/23] usb: chipidea: Emulate OTGSC interrupt enable path
From: Peter Chen @ 2016-10-21  2:14 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <147699579088.21058.4379586947317571921@sboyd-linaro>

On Thu, Oct 20, 2016 at 01:36:30PM -0700, Stephen Boyd wrote:
> Quoting Peter Chen (2016-10-20 03:10:18)
> > On Wed, Oct 19, 2016 at 11:55:29PM -0700, Stephen Boyd wrote:
> > > Quoting Peter Chen (2016-10-19 01:02:11)
> > > > On Tue, Oct 18, 2016 at 06:53:07PM -0700, Stephen Boyd wrote:
> > > > > If you're asking if I've made modifications to extcon-usb-gpio, then the
> > > > > answer is no. The branch on linaro.org git server from the cover-letter
> > > > > is the branch I've used to test this with. This patch is specifically to
> > > > > fix issues with that design on the db410c board that has only one pin
> > > > > for ID and vbus detection. It's the schematic that we've discussed in
> > > > > another thread.
> > > > > 
> > > > > extcon-usb-gpio sends two extcon events, EXTCON_USB_HOST (for the id
> > > > > pin) and EXTCON_USB (for the vbus). So afaik it does support vbus
> > > > > events.
> > > > > 
> > > > 
> > > > Hmm, in fact, your ID event is the same with vbus event, you take
> > > > external vbus event as ID event for extcon-usb-gpio handling. Yes,
> > > > it can work due to it sends EXTCON_USB_HOST event first.
> > > > 
> > > > Where you change the USB_SW_SEL_PM pin?
> > > 
> > > Currently that is done with the mux driver I sent based on the extcon
> > > event. We don't know if that's before or after the controller handles
> > > the extcon event though, so the pin should probably be changed from the
> > > chipidea driver instead to be more explicit. Why do you ask though?
> > 
> > I was just curious how you handle it, now I am clear. From my point,
> > the suitable way may be: mux driver + user app (echo role through
> > debugfs). The extcon-usb-gpio is not necessary, since you have already
> > known role at mux driver.
> > 
> > The current kernel has no framework to handle dual-role switch at kernel
> > space.
> 
> Ok. I'm planning that as future work after this set of patches is
> merged.
> 
> > > > @@ -1963,6 +1963,8 @@ static int udc_id_switch_for_device(struct ci_hdrc *ci)
> > > >                 /* Clear and enable BSV irq */
> > > >                 hw_write_otgsc(ci, OTGSC_BSVIS | OTGSC_BSVIE,
> > > >                                         OTGSC_BSVIS | OTGSC_BSVIE);
> > > > +       /* vbus change may has already been occurred */
> > > 
> > > "vbus change may have already occurred"?
> > 
> > Yes, will change.
> > 
> 
> Great. Should I wait to incorporate your change into my series, or will
> you apply the usb patches and Kishon can apply the phy patches?  This
> patch #11 should be dropped, but otherwise I don't think there's
> anything left to do for this series.

I tested my patch, it works well at my side, if it is ok for you, please
ack it, I will apply it as well as your chipidea series after your
gpu fix patch at greg's usb-next tree.

Is it ok for you?

-- 

Best Regards,
Peter Chen

^ permalink raw reply

* [PATCH v5 23/23] phy: Add support for Qualcomm's USB HS phy
From: Peter Chen @ 2016-10-21  2:20 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <147700563857.2550.16732518381302920183@sboyd-linaro>

On Thu, Oct 20, 2016 at 04:20:38PM -0700, Stephen Boyd wrote:
> Quoting Stephen Boyd (2016-10-17 18:56:36)
> > +
> > +static int
> > +qcom_usb_hs_phy_vbus_notifier(struct notifier_block *nb, unsigned long event,
> > +                             void *ptr)
> > +{
> > +       struct qcom_usb_hs_phy *uphy;
> > +       int is_host;
> > +       u8 addr;
> > +
> > +       uphy = container_of(nb, struct qcom_usb_hs_phy, vbus_notify);
> > +       is_host = extcon_get_cable_state_(uphy->id_edev, EXTCON_USB_HOST);
> 
> Please don't apply this patch. This call now deadlocks on v4.9-rc1
> because of how extcon_get_cable_state_() now grabs a lock that is
> already held here when we're inside the notifier. It's not really
> required that we grab the lock in extcon there, but this has exposed a
> flaw in the logic anyway. We don't know if the id pin is going to toggle
> before or after this function is called, so we should really keep track
> of both vbus and id state in this driver and then do the same ulpi
> writes from two different notifiers for both vbus and id pin. We would
> be duplicating work sometimes, but that's pretty much the best solution
> I can come up with. Otherwise it's racy.
> 

Why you need to care id status? If EXTCON_USB event has happened, and
event is true, you can set, otherwise, it is clear operation, that's
to say you may not need have id extcon phandle, do you think so?

-- 

Best Regards,
Peter Chen

^ permalink raw reply

* [PATCH V4 3/3] Revert "ACPI, PCI, IRQ: separate ISA penalty calculation"
From: Bjorn Helgaas @ 2016-10-21  2:31 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1476915664-27231-4-git-send-email-okaya@codeaurora.org>

On Wed, Oct 19, 2016 at 06:21:04PM -0400, Sinan Kaya wrote:
> This reverts commit f7eca374f000 ("ACPI,PCI,IRQ: separate ISA penalty
> calculation") and commit 487cf917ed0d ("revert "ACPI, PCI, IRQ: remove
> redundant code in acpi_irq_penalty_init()"").
> 
> Now that we understand the real issue (SCI and ISA penalty getting
> calculated before ACPI start), there is no need for special handling
> for ISA interrupts.
> 
> Let's try to simplify the code one more time to share code.

I'm sort of OK with this, but it's not exactly a revert of the above
(the commits you mention don't check "link->irq.initialized == 1".

Previously acpi_irq_penalty_init() looked at _PRS info ("possible"
IRQs), but now we won't.  Maybe that's good; I dunno.  But it should
be mentioned.

And I don't think it fixes a user-visible problem, so it doesn't need
to be applied immediately.  I'm not sure this is worth doing by
itself; maybe it should wait until we can do more cleanup and think
about all these issues together?

> Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
> ---
>  arch/x86/pci/acpi.c         |  1 -
>  drivers/acpi/pci_link.c     | 44 +++++---------------------------------------
>  include/acpi/acpi_drivers.h |  1 -
>  3 files changed, 5 insertions(+), 41 deletions(-)
> 
> diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
> index 3cd6983..b2a4e2a 100644
> --- a/arch/x86/pci/acpi.c
> +++ b/arch/x86/pci/acpi.c
> @@ -396,7 +396,6 @@ int __init pci_acpi_init(void)
>  		return -ENODEV;
>  
>  	printk(KERN_INFO "PCI: Using ACPI for IRQ routing\n");
> -	acpi_irq_penalty_init();
>  	pcibios_enable_irq = acpi_pci_irq_enable;
>  	pcibios_disable_irq = acpi_pci_irq_disable;
>  	x86_init.pci.init_irq = x86_init_noop;
> diff --git a/drivers/acpi/pci_link.c b/drivers/acpi/pci_link.c
> index 294b190..dd14d78 100644
> --- a/drivers/acpi/pci_link.c
> +++ b/drivers/acpi/pci_link.c
> @@ -478,7 +478,8 @@ static int acpi_irq_pci_sharing_penalty(int irq)
>  		 * If a link is active, penalize its IRQ heavily
>  		 * so we try to choose a different IRQ.
>  		 */
> -		if (link->irq.active && link->irq.active == irq)
> +		if ((link->irq.active && link->irq.active == irq) &&
> +				(link->irq.initialized == 1))
>  			penalty += PIRQ_PENALTY_PCI_USING;
>  
>  		/*
> @@ -501,45 +502,10 @@ static int acpi_irq_get_penalty(int irq)
>  		penalty += sci_penalty;
>  
>  	if (irq < ACPI_MAX_ISA_IRQS)
> -		return penalty + acpi_isa_irq_penalty[irq];
> +		penalty += acpi_isa_irq_penalty[irq];
>  
> -	return penalty + acpi_irq_pci_sharing_penalty(irq);
> -}
> -
> -int __init acpi_irq_penalty_init(void)
> -{
> -	struct acpi_pci_link *link;
> -	int i;
> -
> -	/*
> -	 * Update penalties to facilitate IRQ balancing.
> -	 */
> -	list_for_each_entry(link, &acpi_link_list, list) {
> -
> -		/*
> -		 * reflect the possible and active irqs in the penalty table --
> -		 * useful for breaking ties.
> -		 */
> -		if (link->irq.possible_count) {
> -			int penalty =
> -			    PIRQ_PENALTY_PCI_POSSIBLE /
> -			    link->irq.possible_count;
> -
> -			for (i = 0; i < link->irq.possible_count; i++) {
> -				if (link->irq.possible[i] < ACPI_MAX_ISA_IRQS)
> -					acpi_isa_irq_penalty[link->irq.
> -							 possible[i]] +=
> -					    penalty;
> -			}
> -
> -		} else if (link->irq.active &&
> -				(link->irq.active < ACPI_MAX_ISA_IRQS)) {
> -			acpi_isa_irq_penalty[link->irq.active] +=
> -			    PIRQ_PENALTY_PCI_POSSIBLE;
> -		}
> -	}
> -
> -	return 0;
> +	penalty += acpi_irq_pci_sharing_penalty(irq);
> +	return penalty;
>  }
>  
>  static int acpi_irq_balance = -1;	/* 0: static, 1: balance */
> diff --git a/include/acpi/acpi_drivers.h b/include/acpi/acpi_drivers.h
> index 29c6912..797ae2e 100644
> --- a/include/acpi/acpi_drivers.h
> +++ b/include/acpi/acpi_drivers.h
> @@ -78,7 +78,6 @@
>  
>  /* ACPI PCI Interrupt Link (pci_link.c) */
>  
> -int acpi_irq_penalty_init(void);
>  int acpi_pci_link_allocate_irq(acpi_handle handle, int index, int *triggering,
>  			       int *polarity, char **name);
>  int acpi_pci_link_free_irq(acpi_handle handle);
> -- 
> 1.9.1
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH 4/6] ARM: sun5i: Add SPI2 pins
From: Chen-Yu Tsai @ 2016-10-21  2:38 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <2a041979c4cc262535d204e6519d8a25fbbc3a94.1476704881.git-series.maxime.ripard@free-electrons.com>

On Mon, Oct 17, 2016 at 7:49 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> All the sun5i have the SPI2 pins exposed on the PE bank. Add them to the
> DT.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Acked-by: Chen-Yu Tsai <wens@csie.org>

^ permalink raw reply

* [PATCH V3 1/3] ACPI, PCI IRQ: add PCI_USING penalty for ISA interrupts
From: Bjorn Helgaas @ 2016-10-21  2:41 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <a418cf9d-5eeb-a588-6653-fd00e0c2693c@codeaurora.org>

On Thu, Oct 20, 2016 at 01:01:04PM -0700, Sinan Kaya wrote:
> On 10/19/2016 3:44 PM, Bjorn Helgaas wrote:

> >   - Maintain a mapping of (IRQ, penalty).  Initially all penalties are
> >     zero.  This is for *all* IRQs, not just ISA ones.  This could be a
> >     linked list, but the structure is not important as long as we can
> >     add things dynamically.
> 
> Dynamic allocation doesn't work due to early calls from x86 architecture.
> This is the reason why we iterate the link objects.

Where exactly is this early penalization?  That seems to be the
biggest problem.  Well, maybe the question of ACPI core parsing of
_CRS/_PRS is a bigger structural problem, but the dynamic allocation
thing at least seems solvable.

^ permalink raw reply

* [PATCH 6/6] ARM: sun5i: chip: Add optional buses
From: Chen-Yu Tsai @ 2016-10-21  2:48 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <54f17420e7532087c4c63db46a282bfc1678d39e.1476704881.git-series.maxime.ripard@free-electrons.com>

On Mon, Oct 17, 2016 at 7:49 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> The I2C1 and SPI2 buses are exposed on the CHIP headers, and are not
> explicitly dedicated to anything.
>
> Add them to the DTS with the muxing already set, but keep them disabled.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Acked-by: Chen-Yu Tsai <wens@csie.org>

The CHIP docs don't mention SPI2 though.

^ permalink raw reply

* [PATCH 3/6] ARM: sun5i: Rename A10s pins
From: Chen-Yu Tsai @ 2016-10-21  2:49 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <926093bcce58496cdb5cea55aaa65e958d36cb76.1476704881.git-series.maxime.ripard@free-electrons.com>

On Mon, Oct 17, 2016 at 7:49 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> The SPI2 pins on the sun5i PB bank are only available on the A10s. Rename
> the A10s only bank so that it doesn't confuse people on the other SoCs
> whose indexing would start at b.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Acked-by: Chen-Yu Tsai <wens@csie.org>

^ permalink raw reply

* [PATCH 1/6] ARM: sun5i: chip: Enable Wi-Fi SDIO chip
From: Chen-Yu Tsai @ 2016-10-21  2:51 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <468cbaad185a2bde92f1015a1c286f1e1ef55850.1476704881.git-series.maxime.ripard@free-electrons.com>

On Mon, Oct 17, 2016 at 7:48 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> The WiFi chip is powered through a GPIO and two regulators in parallel.
> Since that case is not supported yet, just set them as always on before we
> rework the regulator framework to deal with those.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Acked-by: Chen-Yu Tsai <wens@csie.org>

^ permalink raw reply

* [PATCH v2] mmc: sunxi: Prevent against null dereference for vmmc
From: Chen-Yu Tsai @ 2016-10-21  2:52 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161019133304.22915-1-maxime.ripard@free-electrons.com>

On Wed, Oct 19, 2016 at 9:33 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> VMMC is an optional regulator, which means that mmc_regulator_get_supply
> will only return an error in case of a deferred probe, but not when the
> regulator is not set in the DT.
>
> However, the sunxi driver assumes that VMMC is always there, and doesn't
> check the value of the regulator pointer before using it, which obviously
> leads to a (close to) null pointer dereference.
>
> Add proper checks to prevent that.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Acked-by: Chen-Yu Tsai <wens@csie.org>

^ permalink raw reply

* [PATCH 5/6] ARM: sun5i: Add RGB 565 LCD pins
From: Chen-Yu Tsai @ 2016-10-21  2:53 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <46596d638c314a117c55e6a9086669358b121f2b.1476704881.git-series.maxime.ripard@free-electrons.com>

On Mon, Oct 17, 2016 at 7:49 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Some boards use the LCD in RGB565. Enable the pin muxing option.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Acked-by: Chen-Yu Tsai <wens@csie.org>

^ permalink raw reply

* [PATCH V4 3/3] Revert "ACPI, PCI, IRQ: separate ISA penalty calculation"
From: Sinan Kaya @ 2016-10-21  2:58 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161021023109.GD31044@localhost>

On 10/20/2016 7:31 PM, Bjorn Helgaas wrote:
>> Let's try to simplify the code one more time to share code.
> I'm sort of OK with this, but it's not exactly a revert of the above
> (the commits you mention don't check "link->irq.initialized == 1".

I can split the initialized bit. If I remove it from this commit, it can
break the git bisect. That's why, I folded it into this review. I
briefly mentioned about it in the cover letter. It might not be quiet
clear.

> 
> Previously acpi_irq_penalty_init() looked at _PRS info ("possible"
> IRQs), but now we won't.  Maybe that's good; I dunno.  But it should
> be mentioned.

I'm directing all IRQs to  acpi_irq_pci_sharing_penalty function. 
acpi_irq_pci_sharing_penalty checks for the possible values here from
_PRS.

/*
 * penalize the IRQs PCI might use, but not as severely.
 */
for (i = 0; i < link->irq.possible_count; i++)
	if (link->irq.possible[i] == irq)
		penalty += PIRQ_PENALTY_PCI_POSSIBLE /
			link->irq.possible_count;

> 
> And I don't think it fixes a user-visible problem, so it doesn't need
> to be applied immediately.  I'm not sure this is worth doing by
> itself; maybe it should wait until we can do more cleanup and think
> about all these issues together?
> 

It does fix the PCI_USING penalty assignment. 

                if (link->irq.active && link->irq.active == irq)
                         penalty += PIRQ_PENALTY_PCI_USING;


If we drop this patch, then we need
[PATCH V3 1/3] ACPI, PCI IRQ: add PCI_USING penalty for ISA interrupts

http://www.gossamer-threads.com/lists/linux/kernel/2547605

as somebody needs to increment the penalty with PCI_USING when IRQ is assigned
for a given ISA IRQ.

We might as well take [PATCH V4 1/3], [PATCH V4 2/3] and [PATCH V3 1/3]
for this regression.


-- 
Sinan Kaya
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

* [PATCH 2/6] ARM: sun5i: chip: add a node for the w1 gpio controller
From: Chen-Yu Tsai @ 2016-10-21  3:01 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <a132bfdc6f4eae5540f1a3df4b68ba9bba9d0935.1476704881.git-series.maxime.ripard@free-electrons.com>

On Mon, Oct 17, 2016 at 7:48 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> From: Antoine Tenart <antoine.tenart@free-electrons.com>
>
> The CHIP uses a 1-Wire bus to discover the DIPs. Enable the bus in the DT.
>
> Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>

Acked-by: Chen-Yu Tsai <wens@csie.org>

^ permalink raw reply

* [PATCH V3 1/3] ACPI, PCI IRQ: add PCI_USING penalty for ISA interrupts
From: Sinan Kaya @ 2016-10-21  3:01 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161021024111.GA24336@localhost>

On 10/20/2016 7:41 PM, Bjorn Helgaas wrote:
> On Thu, Oct 20, 2016 at 01:01:04PM -0700, Sinan Kaya wrote:
>> On 10/19/2016 3:44 PM, Bjorn Helgaas wrote:
> 
>>>   - Maintain a mapping of (IRQ, penalty).  Initially all penalties are
>>>     zero.  This is for *all* IRQs, not just ISA ones.  This could be a
>>>     linked list, but the structure is not important as long as we can
>>>     add things dynamically.
>>
>> Dynamic allocation doesn't work due to early calls from x86 architecture.
>> This is the reason why we iterate the link objects.
> 
> Where exactly is this early penalization?  That seems to be the
> biggest problem.  Well, maybe the question of ACPI core parsing of
> _CRS/_PRS is a bigger structural problem, but the dynamic allocation
> thing at least seems solvable.
> 

http://marc.info/?l=linux-acpi&m=145580159209240&w=2


-- 
Sinan Kaya
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

* [PATCH 0/6] ARM: sun5i: chip: Misc improvements
From: Chen-Yu Tsai @ 2016-10-21  3:02 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <cover.92d041a0a6fe40f1c8839cabb70247445eaffdfb.1476704881.git-series.maxime.ripard@free-electrons.com>

On Mon, Oct 17, 2016 at 7:48 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Hi,
>
> This is a bunch of patches I gathered for the CHIP, that enables a few
> things, like the WiFi regulators (and its associated power sequence), a few
> optional buses, etc.

FYI this series makes more sense if you mention the Pocket CHIP DT overlays.

ChenYu

>
> Let me know what you think,
> Maxime
>
> Antoine Tenart (1):
>   ARM: sun5i: chip: add a node for the w1 gpio controller
>
> Maxime Ripard (5):
>   ARM: sun5i: chip: Enable Wi-Fi SDIO chip
>   ARM: sun5i: Rename A10s pins
>   ARM: sun5i: Add SPI2 pins
>   ARM: sun5i: Add RGB 565 LCD pins
>   ARM: sun5i: chip: Add optional buses
>
>  arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts |  4 +-
>  arch/arm/boot/dts/sun5i-a10s.dtsi                |  4 +-
>  arch/arm/boot/dts/sun5i-r8-chip.dts              | 69 +++++++++++++++++-
>  arch/arm/boot/dts/sun5i.dtsi                     | 24 ++++++-
>  4 files changed, 97 insertions(+), 4 deletions(-)
>
> --
> git-series 0.8.10

^ permalink raw reply

* [PATCH 1/1] crypto: atmel-aes: fix compiler error when VERBOSE_DEBUG is defined
From: Herbert Xu @ 2016-10-21  3:09 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <605a4f64ee501aeaffbd43b7b45fd9b3d997bd7b.1475167206.git.cyrille.pitchen@atmel.com>

On Thu, Sep 29, 2016 at 06:46:57PM +0200, Cyrille Pitchen wrote:
> This patch fixes a compiler error when VERBOSE_DEBUG is defined. Indeed,
> in atmel_aes_write(), the 3rd argument of atmel_aes_reg_name() was
> missing.
> 
> Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>
> Reported-by: Levent Demir <levent.demir@inria.fr>

Patch applied.  Thanks.
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply

* [PATCH v2] ARM: imx: gpc: Initialize all power domains
From: Shawn Guo @ 2016-10-21  3:11 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1477013309-2808-1-git-send-email-festevam@gmail.com>

On Thu, Oct 20, 2016 at 11:28:29PM -0200, Fabio Estevam wrote:
> From: Fabio Estevam <fabio.estevam@nxp.com>
> 
> Since commit 0159ec670763dd ("PM / Domains: Verify the PM domain is present
> when adding a provider") the following regression is observed on imx6:
> 
> imx-gpc: probe of 20dc000.gpc failed with error -22
> 
> The imx-gpc driver probe failure causes several issues such as:
> 
> - When booting a kernel built with multi_v7_defconfig a kernel crash is
> seen.
> 
> - When booting a kernel built with imx_v6_v7_defconfig the Etnaviv GPU
> driver is not loaded due to the lack of power domains.
> 
> The gpc probe fails because of_genpd_add_provider_onecell() now checks
> if all the domains are initialized via pm_genpd_present() function
> and it fails because not all the power domains are initialized.

Thanks for the update.  Now we understand that this is a regression
caused by power domain core change.  But my question on why kernel
crashes with multi_v7_defconfig but not with imx_v6_v7_defconfig stays
unanswered.

Shawn

> 
> In order to fix this error, initialize all the power domains from
> imx_gpc_domains[], not only the imx6q_pu_domain.base one.
> 
> Reported-by: Olof's autobooter <build@lixom.net>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> ---
>  arch/arm/mach-imx/gpc.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-imx/gpc.c b/arch/arm/mach-imx/gpc.c
> index 0df062d..d0463e9 100644
> --- a/arch/arm/mach-imx/gpc.c
> +++ b/arch/arm/mach-imx/gpc.c
> @@ -430,7 +430,8 @@ static int imx_gpc_genpd_init(struct device *dev, struct regulator *pu_reg)
>  	if (!IS_ENABLED(CONFIG_PM_GENERIC_DOMAINS))
>  		return 0;
>  
> -	pm_genpd_init(&imx6q_pu_domain.base, NULL, false);
> +	for (i = 0; i < ARRAY_SIZE(imx_gpc_domains); i++)
> +		pm_genpd_init(imx_gpc_domains[i], NULL, false);
>  	return of_genpd_add_provider_onecell(dev->of_node,
>  					     &imx_gpc_onecell_data);
>  
> -- 
> 2.7.4
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply

* [PATCH v2 1/1] crypto: atmel-aes: add support to the XTS mode
From: Herbert Xu @ 2016-10-21  3:12 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <5ba0856b4ef013fa22c8d5ef00a7d97efe63d61f.1475497672.git.cyrille.pitchen@atmel.com>

On Mon, Oct 03, 2016 at 02:33:16PM +0200, Cyrille Pitchen wrote:
> This patch adds the xts(aes) algorithm, which is supported from
> hardware version 0x500 and above (sama5d2x).
> 
> Signed-off-by: Cyrille Pitchen <cyrille.pitchen@atmel.com>

Patch applied.  Thanks.
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply

* [PATCH v4 0/2] Improve DMA chaining for ahash requests
From: Herbert Xu @ 2016-10-21  3:13 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161005075633.12711-1-romain.perier@free-electrons.com>

On Wed, Oct 05, 2016 at 09:56:31AM +0200, Romain Perier wrote:
> This series contain performance improvement regarding ahash requests.
> So far, ahash requests were systematically not chained at the DMA level.
> However, in some case, like this is the case by using IPSec, some ahash
> requests can be processed directly by the engine, and don't have
> intermediaire partial update states.
> 
> This series firstly re-work the way outer IVs are copied from the SRAM
> into the dma pool. To do so, we introduce a common dma pool for all type
> of requests that contains outer results (like IV or digest). Then, for
> ahash requests that can be processed directly by the engine, outer
> results are copied from the SRAM into the common dma pool. These requests
> are then allowed to be chained at the DMA level.
> 
> 
> Benchmarking results with iperf throught IPSec
> ==============================================
> 		ESP			AH
> 
> Before		343 Mbits/s		492 Mbits/s
> After		422 Mbits/s		577 Mbits/s
> Improvement	+23%			+17%
> 
> Romain Perier (2):
>   crypto: marvell - Use an unique pool to copy results of requests
>   crypto: marvell - Don't break chain for computable last ahash requests
> 
>  drivers/crypto/marvell/cesa.c   |  4 ---
>  drivers/crypto/marvell/cesa.h   |  5 ++--
>  drivers/crypto/marvell/cipher.c |  8 +++--
>  drivers/crypto/marvell/hash.c   | 65 +++++++++++++++++++++++++++++++----------
>  drivers/crypto/marvell/tdma.c   | 28 +++++++++---------
>  5 files changed, 70 insertions(+), 40 deletions(-)

All applied.  Thanks.
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

^ permalink raw reply

* [PATCH] drm/sun4i: Add a few formats
From: Chen-Yu Tsai @ 2016-10-21  3:15 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20161018084614.2443-1-maxime.ripard@free-electrons.com>

On Tue, Oct 18, 2016 at 4:46 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> The planes can do more than what was previously exposed. Add support for
> them.
>
> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> ---
>  drivers/gpu/drm/sun4i/sun4i_backend.c | 20 ++++++++++++++++++++
>  drivers/gpu/drm/sun4i/sun4i_layer.c   |  6 ++++++
>  2 files changed, 26 insertions(+)
>
> diff --git a/drivers/gpu/drm/sun4i/sun4i_backend.c b/drivers/gpu/drm/sun4i/sun4i_backend.c
> index afb7ddf660ef..b184a476a480 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_backend.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_backend.c
> @@ -96,6 +96,22 @@ static int sun4i_backend_drm_format_to_layer(struct drm_plane *plane,
>                 *mode = SUN4I_BACKEND_LAY_FBFMT_ARGB8888;
>                 break;
>
> +       case DRM_FORMAT_ARGB4444:
> +               *mode = SUN4I_BACKEND_LAY_FBFMT_ARGB4444;
> +               break;
> +
> +       case DRM_FORMAT_ARGB1555:
> +               *mode = SUN4I_BACKEND_LAY_FBFMT_ARGB1555;
> +               break;
> +
> +       case DRM_FORMAT_RGBA5551:
> +               *mode = SUN4I_BACKEND_LAY_FBFMT_RGBA5551;
> +               break;
> +
> +       case DRM_FORMAT_RGBA4444:
> +               *mode = SUN4I_BACKEND_LAY_FBFMT_RGBA4444;

The A20 manual only lists ARGB4444, not RGBA4444. There might be
some discrepancy here. We can deal with them

Also there are some more formats missing from the list, could you
add them as well?

> +               break;
> +
>         case DRM_FORMAT_XRGB8888:
>                 *mode = SUN4I_BACKEND_LAY_FBFMT_XRGB8888;
>                 break;
> @@ -104,6 +120,10 @@ static int sun4i_backend_drm_format_to_layer(struct drm_plane *plane,
>                 *mode = SUN4I_BACKEND_LAY_FBFMT_RGB888;
>                 break;
>
> +       case DRM_FORMAT_RGB565:
> +               *mode = SUN4I_BACKEND_LAY_FBFMT_RGB565;
> +               break;
> +
>         default:
>                 return -EINVAL;
>         }
> diff --git a/drivers/gpu/drm/sun4i/sun4i_layer.c b/drivers/gpu/drm/sun4i/sun4i_layer.c
> index f0035bf5efea..5d53c977bca5 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_layer.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_layer.c
> @@ -73,12 +73,18 @@ static const struct drm_plane_funcs sun4i_backend_layer_funcs = {
>  static const uint32_t sun4i_backend_layer_formats_primary[] = {
>         DRM_FORMAT_ARGB8888,
>         DRM_FORMAT_RGB888,
> +       DRM_FORMAT_RGB565,
>         DRM_FORMAT_XRGB8888,
>  };
>
>  static const uint32_t sun4i_backend_layer_formats_overlay[] = {
>         DRM_FORMAT_ARGB8888,
> +       DRM_FORMAT_ARGB4444,
> +       DRM_FORMAT_ARGB1555,
> +       DRM_FORMAT_RGBA5551,
> +       DRM_FORMAT_RGBA4444,
>         DRM_FORMAT_RGB888,
> +       DRM_FORMAT_RGB565,
>         DRM_FORMAT_XRGB8888,

Could you explain in the commit log why these 2 aren't the same?

Thanks
ChenYu

>  };
>
> --
> 2.9.3
>

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox