Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
* iMX6Q FEC: transmit queue 0 timed out
From: Shawn Guo @ 2014-07-22  8:15 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAOpc7mHvddM1bCex13yPTRrEkFqYvk2YHYajZeMn+MG83neUBA@mail.gmail.com>

On Wed, Jul 16, 2014 at 10:41:10AM +0200, Holger Schurig wrote:
> Andy,
> 
> to revive an old thread: I now got ethernet working. Basically, I
> needed to set the system so that the PHY is generating the ref-clock.
> I found even code in arch/arm/mach-imx/mach-imx6q.c that controls
> setting of GPR1[21] from the device tree. However, I wasn't really
> able to come up with a device-tree that triggers the code
> IMX6Q_GPR1_ENET_CLK_SEL_PAD. For example, Neither
> Documentation/devicetree/bindings/net/fsl-fec.txt nor any other file
> there mention anything on how to do this.
> 
> Currently I disable the 3rd clock. I changed the default
>          clocks = <&clks 117>, <&clks 117>, <&clks 190>;
>          clock-names = "ipg", "ahb", "ptp";
> (from imx6qdl.dtsi) to my dts:
>          clocks = <&clks 117>, <&clks 117>;
>          clock-names = "ipg", "ahb";
> 
> Would I have needed to create some dummy clock, e.g. "ext-phy-clk" and
> specified that as a third clock in my dts?

Since in your setup PHY is generating the reference clock, you need to
define this clock in your board dts, and overwrite the 'ptp' clock with
it, something like the following.

clocks {
	#address-cells = <1>;
	#size-cells = <0>;

	rmii_clk: clock at 0 {
		compatible = "fixed-clock";
		reg = <0>;
		#clock-cells = <0>;
		clock-frequency = <25000000>;  /* 25MHz for example */
		clock-output-names = "rmii_ref_clk";
	};
};

&fec {
        clocks = <&clks 117>, <&clks 117>, <&rmii_clk>;
};

^ permalink raw reply

* [PATCH v7 8/9] ARM: vdso initialization, mapping, and synchronization
From: Will Deacon @ 2014-07-22  8:13 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CALCETrXGi3a3G=dH2R6-mu2BwGdEyn3AXrGVRstye6zPO1mFxA@mail.gmail.com>

On Tue, Jul 22, 2014 at 01:14:35AM +0100, Andy Lutomirski wrote:
> On Wed, Jul 2, 2014 at 11:54 AM, Will Deacon <will.deacon@arm.com> wrote:
> > Ok, so that explains why things are working at the moment and it sounds like
> > we have some wiggle room too. I'll look at moving the datapage anyway, since
> > having these artificial limits is error-prone and fragile, but I don't think
> > it's something we need to panic about immediately.
> >
> > Also, if you get to the bottom of your binutils issues with the section
> > allocation, that might work for us since we don't really have any legacy
> > binutils supporting arm64.
> 
> Just in case anyone still cares about this thread, moving the vvar
> area back before the vdso text is queued up for 3.17.  I gave up on
> reliably keeping binutils happy with my ugly hack.

The same change is also queued for arm64.

Thanks Andy,

Will

^ permalink raw reply

* [PATCH 8/9] usb: phy: am335x: call usb_gen_phy_init()/usb_gen_phy_shutdown() in am335x_init()/am335x_shutdown()
From: Lothar Waßmann @ 2014-07-22  8:06 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20140721151043.GF6852@saruman.home>

Hi,

Felipe Balbi wrote:
> Hi,,
> 
> On Mon, Jul 21, 2014 at 10:03:07AM +0200, Lothar Wa?mann wrote:
> > Hi,
> > 
> > > On Fri, Jul 18, 2014 at 11:31:29AM +0200, Lothar Wa?mann wrote:
> > > > This patch makes it possible to use the musb driver with HW that
> > > > requires external regulators or clocks.
> > > 
> > > can you provide an example of such HW ? Are you not using the internal
> > > PHYs ?
> > > 
> > The Ka-Ro electronics TX48 module uses the mmc0_clk pin as VBUSEN
> > rathern than usb0_drvvbus. This patch makes it possible to use an
> > external regulator to handle the VBUS switch through the 'vcc-supply'
> > property of the underlying generic_phy device.
> 
> OK, I get it now. But why would not use usb0_drvvbus ? You could still
> route usb0_drvvbus to the regulator enable pin and the regulator would
> be enabled for you once correct values are written to the IP's mailbox.
> 
> I suppose this has something to do with layout constraints ?
> 
Yes. The usb0_drvvbus is used for a different purpose.


Lothar Wa?mann
-- 
___________________________________________________________

Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________

^ permalink raw reply

* [PATCH 1/3] ARM: exynos: remove unused <mach/memory.h>
From: Uwe Kleine-König @ 2014-07-22  7:51 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1404295043-6661-1-git-send-email-u.kleine-koenig@pengutronix.de>

Hello,

who takes care of this series?

In fact they are all orthogonal to each other.

The first patch

	ARM: exynos: remove unused <mach/memory.h>

has been reviewed and tested by Tomasz Figa and Sachin Kamat. Can the
Samsung people pick it up? Or armsoc?

Patch 2 (v2!)

	ARM: remove remaining definitions of PLAT_PHYS_OFFSET from <mach/memory.h>

touches several arch/arm/mach-*/include/mach/memory.h and
arch/arm/Kconfig. armsoc? Russell?

Patch 3 fixes a warning regarding nommu and touches the Kconfig entry
for Integrator and Renesas (non-multiplatform). armsoc?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

^ permalink raw reply

* [PATCH] ARM: dts: imx6qdl-sabresd: add always on pcie regulator
From: Lucas Stach @ 2014-07-22  7:51 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20140722025708.GU8537@dragon>

Hi Shawn,

Am Dienstag, den 22.07.2014, 10:57 +0800 schrieb Shawn Guo:
> On Fri, Jul 18, 2014 at 08:14:30PM +0200, Lucas Stach wrote:
> > Everything in the PCI specification assumes devices to be
> > enumerable on startup. This is only possible if they have
> > power available.
> > 
> > A future improvement may allow this regulator to be switched
> > off for D3hot and D3cold power states, but there is a lot
> > of work to do the pcie host controller side for this to work.
> > To keep things simple always enable the regulator for now.
> > 
> > Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> 
> Just curious if this fixes any known PCIe issue?

Yes this allows PCIe devices to work on my SabreSD board. I don't know
if it's required for all revisions, the schematics certainly show a
mounting option where the load switch isn't populated but bridged by 0R
resistor.

> 
> > ---
> >  arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 12 ++++++++++++
> >  1 file changed, 12 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> > index ec43dde78525..bbbd501098e6 100644
> > --- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> > +++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> > @@ -54,6 +54,17 @@
> >  			gpio = <&gpio4 10 0>;
> >  			enable-active-high;
> >  		};
> > +
> > +		reg_pcie: regulator at 3 {
> > +			compatible = "regulator-fixed";
> > +			reg = <3>;
> > +			regulator-name = "pcie-supply";
> 
> I would start asking to name the regulator in the same way that board
> document like schematics names it.  In this case, it should be
> "MPCIE_3V3".
> 
> > +			regulator-min-microvolt = <3300000>;
> > +			regulator-max-microvolt = <3300000>;
> > +			gpio = <&gpio3 19 0>;
> > +			regulator-always-on;
> > +			enable-active-high;
> > +		};
> >  	};
> >  
> >  	gpio-keys {
> > @@ -323,6 +334,7 @@
> >  				MX6QDL_PAD_ENET_TXD1__GPIO1_IO29 0x80000000
> >  				MX6QDL_PAD_EIM_D22__GPIO3_IO22  0x80000000
> >  				MX6QDL_PAD_ENET_CRS_DV__GPIO1_IO25 0x80000000
> > +				MX6QDL_PAD_EIM_D19__GPIO3_IO19  0x80000000
> 
> No more GPIO setup in hog group, and no more 0x80000000 on pad config.
> Please have a dedicate pinctrl entry for it with a proper config value,
> and refer to the entry in that reg_pcie node.
> 
Ok, will fix.

-- 
Pengutronix e.K.             | Lucas Stach                 |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

^ permalink raw reply

* [PATCH 9/9] usb: musb: musb_am335x: reinstate module loading/unloading support
From: Lothar Waßmann @ 2014-07-22  7:49 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20140718140403.GI24914@saruman.home>

Hi,

Felipe Balbi wrote:
> On Fri, Jul 18, 2014 at 11:31:30AM +0200, Lothar Wa?mann wrote:
> > There is no need to throw the baby out with the bath due to a bad
> > failure analysis. The commit:
> > 7adb5c876e9c usb: musb: Fix panic upon musb_am335x module removal
> > came to a wrong conclusion about the cause of the crash it was
> > "fixing". The real culprit was the phy-am335x module that was removed
> > from underneath its users that were still referencing data from it.
> > After having fixed this in a previous patch, module unloading can be
> > reinstated.
> > 
> > Another bug with module loading/unloading was the fact, that after
> > removing the devices instantiated from DT their 'OF_POPULATED' flag
> > was still set, so that re-loading the module after an unload had no
> > effect. This is also fixed in this patch.
> 
> now this is a good commit log. I still can't see the need for the other
> patch adding try_module_get(), though. Another thing, this needs to be
> reviewed by DT folks too.
> 
Without holding a reference to the phy module, the module may be
unloaded when its resources are still in use which may lead to the
crash observed in the above stated commit.

> > Signed-off-by: Lothar Wa?mann <LW@KARO-electronics.de>
> > ---
> >  drivers/usb/musb/musb_am335x.c |   23 ++++++++++++++++++-----
> >  1 file changed, 18 insertions(+), 5 deletions(-)
> > 
> > diff --git a/drivers/usb/musb/musb_am335x.c b/drivers/usb/musb/musb_am335x.c
> > index 164c868..152a6f5 100644
> > --- a/drivers/usb/musb/musb_am335x.c
> > +++ b/drivers/usb/musb/musb_am335x.c
> > @@ -19,6 +19,22 @@ err:
> >  	return ret;
> >  }
> >  
> > +static int of_remove_populated_child(struct device *dev, void *d)
> > +{
> > +	struct platform_device *pdev = to_platform_device(dev);
> > +
> > +	of_device_unregister(pdev);
> > +	of_node_clear_flag(pdev->dev.of_node, OF_POPULATED);
> 
> I don't think this should be called by drivers; rather by the bus.
> 
Possibly the right thing to do would be to use of_platform_depopulate()
in the remove function to pair up with op_platform_populate() in the
probe function, but doing this results in a crash in
platform_device_del() (called from platform_device_unregister()) when
release_resource() is being called on resources that were never
properly registered with the device:
Unable to handle kernel NULL pointer dereference at virtual address 00000018
pgd = 8dd64000
[00000018] *pgd=8ddc2831, *pte=00000000, *ppte=00000000
Internal error: Oops: 17 [#1] PREEMPT ARM
Modules linked in: musb_am335x(-) [last unloaded: snd]
CPU: 0 PID: 1435 Comm: modprobe Not tainted 3.16.0-rc5-next-20140717-dbg+ #13
task: 8da00880 ti: 8dda0000 task.ti: 8dda0000
PC is at release_resource+0x14/0x7c
LR is at release_resource+0x10/0x7c
pc : [<8003165c>]    lr : [<80031658>]    psr: a0000013
sp : 8dda1ec0  ip : 8dda0000  fp : 00000000
r10: 00000000  r9 : 8dda0000  r8 : 8deb7c10
r7 : 8deb7c00  r6 : 00000200  r5 : 00000001  r4 : 8deed380
r3 : 00000000  r2 : 00000000  r1 : 00000011  r0 : 806772a0
Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 10c5387d  Table: 8dd64019  DAC: 00000015
Process modprobe (pid: 1435, stack limit = 0x8dda0238)
Stack: (0x8dda1ec0 to 0x8dda2000)
1ec0: 8da00880 8deed380 00000001 802f850c 00000000 8deed380 44e10620 44e1062f
1ee0: 8deb7c00 00000000 80398c5c 00000081 8000e904 802f8848 8deb7c10 80398d0c
1f00: 00000000 802f3470 8d8d7200 8ddc84b0 8d92e810 7f0f9014 8d92e844 7f0f7010
1f20: 8d92e810 802f8110 802f80f8 802f68f8 7f0f9014 8d92e810 7f0f9014 802f7238
1f40: 7f0f9014 00000000 20000013 802f6764 7f0f9058 8007ec94 00000000 6273756d
1f60: 336d615f 00783533 8da00880 8000e764 00000001 80053ae4 00000058 76f41000
1f80: 7eb299e8 01290838 00000011 00000081 60000010 0000e854 7eb299e8 01290838
1fa0: 00000011 8000e740 7eb299e8 01290838 012908a0 00000080 00000000 00000001
1fc0: 7eb299e8 01290838 00000011 00000081 012908a0 00000000 01290844 00000000
1fe0: 76eb76f0 7eb2995c 0000a534 76eb76fc 60000010 012908a0 aaaaaaaa aaaaaaaa
[<8003165c>] (release_resource) from [<802f850c>] (platform_device_del+0xb4/0xf4)
[<802f850c>] (platform_device_del) from [<802f8848>] (platform_device_unregister+0xc/0x18)
[<802f8848>] (platform_device_unregister) from [<80398d0c>] (of_platform_device_destroy+0xb0/0xc8)
[<80398d0c>] (of_platform_device_destroy) from [<802f3470>] (device_for_each_child+0x34/0x74)
[<802f3470>] (device_for_each_child) from [<7f0f7010>] (am335x_child_remove+0x10/0x24 [musb_am335x])
[<7f0f7010>] (am335x_child_remove [musb_am335x]) from [<802f8110>] (platform_drv_remove+0x18/0x1c)
[<802f8110>] (platform_drv_remove) from [<802f68f8>] (__device_release_driver+0x70/0xc4)
[<802f68f8>] (__device_release_driver) from [<802f7238>] (driver_detach+0xb4/0xb8)
[<802f7238>] (driver_detach) from [<802f6764>] (bus_remove_driver+0x5c/0xa4)
[<802f6764>] (bus_remove_driver) from [<8007ec94>] (SyS_delete_module+0x120/0x18c)
[<8007ec94>] (SyS_delete_module) from [<8000e740>] (ret_fast_syscall+0x0/0x48)
Code: e1a04000 e59f0068 eb10bac4 e5943010 (e5932018) 
---[ end trace 24ca43dfc1a677d6 ]---

The cause for this seems to be calling platform_device_unregister() on
a device that was created with device_add() (rather than
platform_device_add()).

The call chain for registering a device from of_platform_populate() is:
of_platform_bus_create()
of_platform_device_create_pdata()
of_device_add()
device_add()

The call chain for the of_platform_depopulate() is:
of_platform_device_destroy()
platform_device_unregister()
platform_device_del()
release_resource()

The resources that are being released here have the 'parent' pointer
set to NULL which provokes the crash. This pointer would have been set
up by insert_resource() which is called by platform_device_add() but
not by device_add().

So, the conclusion to me is that of_platform_populate() /
of_platform_depopulate() are broken, because one uses device_*
functions while the other uses the platform_device_* counterparts.

Since there are no current users of of_platform_depopulate() this
obviously has gone unnoticed so far.


Lothar Wa?mann
-- 
___________________________________________________________

Ka-Ro electronics GmbH | Pascalstra?e 22 | D - 52076 Aachen
Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
Gesch?ftsf?hrer: Matthias Kaussen
Handelsregistereintrag: Amtsgericht Aachen, HRB 4996

www.karo-electronics.de | info at karo-electronics.de
___________________________________________________________

^ permalink raw reply

* [PATCH v2] PCI: imx6: fix boot hang when link already enabled
From: Lucas Stach @ 2014-07-22  7:47 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1d83254966df448ea71a08830ad00713@DM2PR0301MB0862.namprd03.prod.outlook.com>

Hi Richard,

Am Dienstag, den 22.07.2014, 07:24 +0000 schrieb
Hong-Xing.Zhu at freescale.com:
> Hi Lucas:
> Thanks for your help on this case firstly.
> See my comments marked by Richard below.
> Best Regards
> Richard Zhu
> 
> 
> > -----Original Message-----
> > From: linux-pci-owner at vger.kernel.org [mailto:linux-pci-owner at vger.kernel.org]
> > On Behalf Of Lucas Stach
> > Sent: Tuesday, July 22, 2014 2:17 AM
> > To: bhelgaas at google.com
> > Cc: linux-pci at vger.kernel.org; Estevam Fabio-R49496; Guo Shawn-R65073; Marek
> > Vasut; d.mueller at elsoft.ch; Zhu Richard-R65037; tharvey at gateworks.com;
> > kernel at pengutronix.de; linux-arm-kernel at lists.infradead.org
> > Subject: [PATCH v2] PCI: imx6: fix boot hang when link already enabled
> > 
> > This fixes a boot hang observed when the bootloader already enabled the PCIe
> > link for it's own use. The fundamental problem is that Freescale forgot to
> > wire up the core reset, so software doesn't have a sane way to get the core
> > into a defined state.
> > 
> > According to the DW PCIe core reference manual configuration of the core may
> > only happen when the LTSSM is disabled, so this is one of the first things we
> > need to do. Apparently this isn't safe to do when the LTSSM is in any other
> > state than "detect" as we observe an instant machine hang when trying to do so
> > while the link is already up.
> > 
> > As a workaround force LTSSM into detect state right before hitting the disable
> > switch.
> > 
> > Reported-by: Fabio Estevam <fabio.estevam@freescale.com>
> > Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> > ---
> > v2: messed up the first submission by omitting a chunk
> > 
> > Fabios delay workaround worked because of the following
> > conditions:
> > 1. The driver gets probed and pulls the peripheral reset GPIO 2. Peripheral is
> > held in reset, so won't answer any link negotiation requests 3. The LTSSM
> > times out and falls back into detect state after 24ms (that's why a 30ms delay
> > helps) 4. After LTSSM entered detect state it's safe to hit the disable switch
> > ---
> >  drivers/pci/host/pci-imx6.c | 11 +++++++++++
> >  1 file changed, 11 insertions(+)
> > 
> > diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c index
> > a568efaa331c..1c4b4b81fe15 100644
> > --- a/drivers/pci/host/pci-imx6.c
> > +++ b/drivers/pci/host/pci-imx6.c
> > @@ -49,6 +49,9 @@ struct imx6_pcie {
> > 
> >  /* PCIe Port Logic registers (memory-mapped) */  #define PL_OFFSET 0x700
> > +#define PCIE_PL_PFLR (PL_OFFSET + 0x08)
> > +#define PCIE_PL_PFLR_LINK_STATE_MASK		(0x3f << 16)
> > +#define PCIE_PL_PFLR_FORCE_LINK			(1 << 15)
> >  #define PCIE_PHY_DEBUG_R0 (PL_OFFSET + 0x28)  #define PCIE_PHY_DEBUG_R1
> > (PL_OFFSET + 0x2c)
> >  #define PCIE_PHY_DEBUG_R1_XMLH_LINK_IN_TRAINING	(1 << 29)
> > @@ -214,7 +217,15 @@ static int imx6q_pcie_abort_handler(unsigned long addr,
> > static int imx6_pcie_assert_core_reset(struct pcie_port *pp)  {
> >  	struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
> > +	u32 val;
> > +
> > +	val = readl(pp->dbi_base + PCIE_PL_PFLR);
> > +	val &= ~PCIE_PL_PFLR_LINK_STATE_MASK;
> > +	val |= PCIE_PL_PFLR_FORCE_LINK;
> > +	writel(val, pp->dbi_base + PCIE_PL_PFLR);
> [Richard] At this point, the port logic register access are relied on the
> pcie clks enable in uboot. Otherwise, kernel would be hang, if the pcie is not enabled
> in uboot ever.

You are right, I'll fix this to check if the LTSSEM and REF_SSP are
enabled in the IOMUX GPR registers. This should give a good indication
whether the bootloader enabled PCIe or not.

Regards,
Lucas
-- 
Pengutronix e.K.             | Lucas Stach                 |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

^ permalink raw reply

* [[RFC PATCH]] gpio: gpio-mxc: make sure gpio is input when request IRQ
From: Shawn Guo @ 2014-07-22  7:42 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <53CE107A.1000000@tqsc.de>

+ Grant and devicetree list

On Tue, Jul 22, 2014 at 09:19:22AM +0200, Markus Niebel wrote:
> Am 22.07.2014 08:28, wrote Shawn Guo:
> > On Wed, Jul 16, 2014 at 03:51:04PM +0200, Markus Niebel wrote:
> >> From: Markus Niebel <Markus.Niebel@tq-group.com>
> >>
> >> When requesting an GPIO irq for imx Soc two things are missing:
> >> - there is no check, if the GPIO is already requested
> >> - there is no check, if the GPIO is configured as input
> >>
> >> The first case can lead to reconfiguring the GPIO pin from third
> >> party while it is used as IRQ pin, second case will (eventually)
> >> prevent IRQ from being seen by SOC becaus the pin is driven by
> >> Soc
> >>
> >> This patch tries to implement (logic taken roughly from gpio-omap)
> >> - basic check if gpio already requested
> >> - if needed requests the gpio and configures as IN.
> >> - if gpio is already requested it is only verified if pin is IN
> >> - gpio is locked as irq
> >>
> >> Tested on a not mainlined i.MX6 based hardware with pin configured
> >> by bootloader as OUT HIGH and expecting a low active IRQ.
> >>
> >> Signed-off-by: Markus Niebel <Markus.Niebel@tq-group.com>
> >> ---
> >>  drivers/gpio/gpio-mxc.c |   35 +++++++++++++++++++++++++++++++++++
> >>  1 file changed, 35 insertions(+)
> >>
> >> diff --git a/drivers/gpio/gpio-mxc.c b/drivers/gpio/gpio-mxc.c
> >> index db83b3c..4316a38 100644
> >> --- a/drivers/gpio/gpio-mxc.c
> >> +++ b/drivers/gpio/gpio-mxc.c
> >> @@ -175,6 +175,31 @@ static int gpio_set_irq_type(struct irq_data *d, u32 type)
> >>  	u32 gpio = port->bgc.gc.base + gpio_idx;
> >>  	int edge;
> >>  	void __iomem *reg = port->base;
> >> +	int ret = 0;
> >> +
> >> +	if (!gpiochip_is_requested(&port->bgc.gc, gpio_idx)) {
> >> +		char label[32];
> >> +
> >> +		snprintf(label, 32, "gpio%u-irq", gpio);
> >> +		ret = gpio_request_one(gpio, GPIOF_DIR_IN, label);
> > 
> > I'm not sure it's correct to call gpio_request_one() from .set_irq_type
> > hook.  It looks like a API usage violation to me.  It should really be
> > called from client driver.
> 
> Thats why it is an RFC. I add Linus Walleij to the cc-list.
> 
> Let me describe the problem:
> 
> Currently client drivers have simply interrupts and interrupt-parent
> in their bindings, but no interrupt-gpios. Therefore in this case a
> client does not know about a dedicated gpio which is to be requested
> and configured.

Okay.  I understand your problem now.  This is an issue in case we
specify a GPIO to be used as interrupt from device tree.  In non-DT
world, client driver knows this is an interrupt on GPIO, and therefore
takes the responsibility to request and configure the GPIO to work as
interrupt.  But in DT case, client driver does not know whether it's an
IRQ line or GPIO based interrupt.  The consequence is that GPIO
subsystem, OF subsystem, client driver, none of the three is requesting
and configuring the GPIO to be used as interrupt.

This is a common issue instead of i.MX specific, and should be addressed
globally, I think.

Shawn

> 
> > 
> >> +	} else {
> >> +		val = readl(port->base + GPIO_GDIR);
> >> +		if (val & BIT(gpio_idx))
> >> +			ret = -EINVAL;
> > 
> > It says that the GPIO is requested by someone, but we're not really sure
> > if it's the correct one, i.e. the one is requesting set_irq_type.
> > 
> 
> Yes, but the current situation is even worse (in my eyes): an IRQ can be requested and an
> independend party can request and configure the gpio as output ...
> 
> >> +	}
> >> +
> >> +	if (ret) {
> >> +		dev_err(port->bgc.gc.dev, "unable to set gpio_idx %u as IN\n",
> >> +			gpio_idx);
> >> +		return ret;
> >> +	}
> > 
> > Having said that, I'm not sure any above changes is really necessary.
> > If any, I would say only gpiochip_is_requested() check makes some sense,
> > but we should just fail out if the GPIO hasn't been requested.  Nothing
> > more can be done in there.
> 
> Going that way as a consequence a reworked device tree binding for gpio irq is needed
> (just like in the platform data days) when providing a gpio number and the client has
> to request gpio and irq - correct me if I'm wrong.
> 
> Maybe here is something needed with deeper knowledge in the gpio subsystem.
> 
> > 
> >> +
> >> +	ret = gpio_lock_as_irq(&port->bgc.gc, gpio_idx);
> >> +	if (ret) {
> >> +		dev_err(port->bgc.gc.dev, "unable to lock gpio_idx %u for IRQ\n",
> >> +			gpio_idx);
> >> +		return ret;
> >> +	}
> > 
> > This and the following changes do make sense to me.
> > 
> > Shawn
> > 
> >>  
> >>  	port->both_edges &= ~(1 << gpio_idx);
> >>  	switch (type) {
> >> @@ -231,6 +256,15 @@ static int gpio_set_irq_type(struct irq_data *d, u32 type)
> >>  	return 0;
> >>  }
> >>  
> >> +static void gpio_irq_shutdown(struct irq_data *d)
> >> +{
> >> +	struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
> >> +	struct mxc_gpio_port *port = gc->private;
> >> +	u32 gpio_idx = d->hwirq;
> >> +
> >> +	gpio_unlock_as_irq(&port->bgc.gc, gpio_idx);
> >> +}
> >> +
> >>  static void mxc_flip_edge(struct mxc_gpio_port *port, u32 gpio)
> >>  {
> >>  	void __iomem *reg = port->base;
> >> @@ -353,6 +387,7 @@ static void __init mxc_gpio_init_gc(struct mxc_gpio_port *port, int irq_base)
> >>  	ct->chip.irq_mask = irq_gc_mask_clr_bit;
> >>  	ct->chip.irq_unmask = irq_gc_mask_set_bit;
> >>  	ct->chip.irq_set_type = gpio_set_irq_type;
> >> +	ct->chip.irq_shutdown = gpio_irq_shutdown;
> >>  	ct->chip.irq_set_wake = gpio_set_wake_irq;
> >>  	ct->regs.ack = GPIO_ISR;
> >>  	ct->regs.mask = GPIO_IMR;
> >> -- 
> >> 1.7.9.5
> >>
> > 
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> > 
> 

^ permalink raw reply

* [GIT PULL v2] nommu fixes for 3.17-rc1
From: Uwe Kleine-König @ 2014-07-22  7:42 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20140711073054.GI11056@pengutronix.de>

Hi Russell,

On Fri, Jul 11, 2014 at 09:30:54AM +0200, Uwe Kleine-K?nig wrote:
> On Tue, Jul 01, 2014 at 11:41:59AM +0200, Uwe Kleine-K?nig wrote:
> > I updated my tag to pull to not include the commit that drops ARM740T,
> > ARM940T and ARM946E-S because of Arnd's concerns. Also the two cleanups
> > that depended on this one are dropped.
> > 
> > (As before) I picked -rc3 as base because 1c2f87c22566..6980c3e2514e~ is
> > broken on nommu. 
> > 
> > The following changes since commit 4c834452aad01531db949414f94f817a86348d59:
> > 
> >   Linux 3.16-rc3 (2014-06-29 14:11:36 -0700)
> > 
> > are available in the git repository at:
> > 
> >   git://git.pengutronix.de/git/ukl/linux.git tags/nommu-for-rmk
> > 
> > for you to fetch changes up to 83de911cf897a4317147dd9cb379378c2c4abf4c:
> > 
> >   ARM: make user_addr_max more robust (2014-07-01 11:12:09 +0200)
> > 
> > ----------------------------------------------------------------
> > Two different fixes for the same problem making some ARM nommu configurations
> > not boot since 3.6-rc1. The problem is that user_addr_max returned the biggest
> > available RAM address which makes some copy_from_user variants fail to read
> > from XIP memory.
> > 
> > Even in the presence of one of the two fixes the other still makes sense, so
> > both patches are included here.
> > 
> > This problem was the last one preventing efm32 boot to a prompt with mainline.
> You neither commented nor pulled this request (at least I didn't find it
> in your repository). Is it still on your radar?
I'd really like to have this in 3.17. Any chances? Would you prefer to
get these patches into your patch tracker?

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-K?nig            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

^ permalink raw reply

* [PATCH v8 00/11] ARM: brcmstb: Add Broadcom STB SoC support
From: Arnd Bergmann @ 2014-07-22  7:35 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1405976886-27807-1-git-send-email-computersforpeace@gmail.com>

On Monday 21 July 2014 14:07:55 Brian Norris wrote:
> I'm taking over the latest resubmission of this patch series.
> There are a few moderate changes for v8 (noted below), but we
> are waiting mostly for an Ack for the reboot driver.
> 
> This patchset contains the board support package for the
> Broadcom BCM7445 ARM-based SoC [1]. These changes contain a
> minimal set of code needed for a BCM7445-based board to boot
> the Linux kernel.
> 
> These changes heavily leverage the OF/devicetree framework. The
> machine is also built into the multi-platform ARMv7 image.
> 
> Changes are also available here:
> 
>   https://github.com/brcm/linux/tree/brcmstb-v8
>   git://github.com/brcm/linux.git +brcmstb-v8

Whole series

Acked-by: Arnd Bergmann <arnd@arndb.de>

I think we should try to get this merged into 3.17, it's already
taken too long and the patches look good.

Please add the core architecture patches for arch/arm into Russell's
patch tracker http://www.arm.linux.org.uk/developer/patches/.

For the platform changes in the first patch, I would prefer to have
Matt pick up the first patch, but we can also apply it directly into
arm-soc if he prefers that.

The reset driver can ideally go through the drivers/power/ maintainers,
but if they are not interested in merging it, we can also take that
through arm-soc. See also my one comment on that driver.

	Arnd

^ permalink raw reply

* [PATCH v8 02/11] power: reset: Add reboot driver for brcmstb
From: Arnd Bergmann @ 2014-07-22  7:28 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1405976886-27807-3-git-send-email-computersforpeace@gmail.com>

On Monday 21 July 2014 14:07:57 Brian Norris wrote:
> diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig
> index 0073633e7699..9782e8d80647 100644
> --- a/arch/arm/mach-bcm/Kconfig
> +++ b/arch/arm/mach-bcm/Kconfig
> @@ -94,6 +94,7 @@ config ARCH_BRCMSTB
>         select MIGHT_HAVE_PCI
>         select HAVE_SMP
>         select HAVE_ARM_ARCH_TIMER
> +       select POWER_RESET_BRCMSTB
>         help
>           Say Y if you intend to run the kernel on a Broadcom ARM-based STB
>           chipset.
> diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
> index bdcf5173e377..fcb9825debe5 100644
> --- a/drivers/power/reset/Kconfig
> +++ b/drivers/power/reset/Kconfig
> @@ -20,6 +20,16 @@ config POWER_RESET_AXXIA
>  
>           Say Y if you have an Axxia family SoC.
>  
> +config POWER_RESET_BRCMSTB
> +       bool "Broadcom STB reset driver"
> +       depends on POWER_RESET && ARCH_BRCMSTB
> +       help
> +         This driver provides restart support for ARM-based Broadcom STB
> +         boards.
> +
> +         Say Y here if you have an ARM-based Broadcom STB board and you wish
> +         to have restart support.
> +
>  config POWER_RESET_GPIO
>         bool "GPIO power-off driver"
>         depends on OF_GPIO && POWER_RESET
> 

(nitpicking)

You shouldn't have both a user-selectable option and 'select' it from
the platform, because it makes it inherently not selectable, in particular
in the combination with 'depends on ARCH_BRCMSTB'.

One way to solve this would be to change the dependency to

config POWER_RESET_BRCMSTB
	bool "Broadcom STB reset driver"
	depends on POWER_RESET && ARM
	depends on ARCH_BRCMSTB || COMPILE_TEST

which in effect would allow building it on any ARM machine as long as
COMPILE_TEST is set (which normally is not).

The same could be expressed using

config POWER_RESET_BRCMSTB
	bool "Broadcom STB reset driver" if COMPILE_TEST
	depends on POWER_RESET && ARM

My preference in this case however would be to just drop the 'select'
statement and add the driver to the defconfig file.

	Arnd

^ permalink raw reply

* [PATCH v2] PCI: imx6: fix boot hang when link already enabled
From: Hong-Xing.Zhu at freescale.com @ 2014-07-22  7:24 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1405966635-7455-1-git-send-email-l.stach@pengutronix.de>

Hi Lucas:
Thanks for your help on this case firstly.
See my comments marked by Richard below.
Best Regards
Richard Zhu


> -----Original Message-----
> From: linux-pci-owner at vger.kernel.org [mailto:linux-pci-owner at vger.kernel.org]
> On Behalf Of Lucas Stach
> Sent: Tuesday, July 22, 2014 2:17 AM
> To: bhelgaas at google.com
> Cc: linux-pci at vger.kernel.org; Estevam Fabio-R49496; Guo Shawn-R65073; Marek
> Vasut; d.mueller at elsoft.ch; Zhu Richard-R65037; tharvey at gateworks.com;
> kernel at pengutronix.de; linux-arm-kernel at lists.infradead.org
> Subject: [PATCH v2] PCI: imx6: fix boot hang when link already enabled
> 
> This fixes a boot hang observed when the bootloader already enabled the PCIe
> link for it's own use. The fundamental problem is that Freescale forgot to
> wire up the core reset, so software doesn't have a sane way to get the core
> into a defined state.
> 
> According to the DW PCIe core reference manual configuration of the core may
> only happen when the LTSSM is disabled, so this is one of the first things we
> need to do. Apparently this isn't safe to do when the LTSSM is in any other
> state than "detect" as we observe an instant machine hang when trying to do so
> while the link is already up.
> 
> As a workaround force LTSSM into detect state right before hitting the disable
> switch.
> 
> Reported-by: Fabio Estevam <fabio.estevam@freescale.com>
> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> ---
> v2: messed up the first submission by omitting a chunk
> 
> Fabios delay workaround worked because of the following
> conditions:
> 1. The driver gets probed and pulls the peripheral reset GPIO 2. Peripheral is
> held in reset, so won't answer any link negotiation requests 3. The LTSSM
> times out and falls back into detect state after 24ms (that's why a 30ms delay
> helps) 4. After LTSSM entered detect state it's safe to hit the disable switch
> ---
>  drivers/pci/host/pci-imx6.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c index
> a568efaa331c..1c4b4b81fe15 100644
> --- a/drivers/pci/host/pci-imx6.c
> +++ b/drivers/pci/host/pci-imx6.c
> @@ -49,6 +49,9 @@ struct imx6_pcie {
> 
>  /* PCIe Port Logic registers (memory-mapped) */  #define PL_OFFSET 0x700
> +#define PCIE_PL_PFLR (PL_OFFSET + 0x08)
> +#define PCIE_PL_PFLR_LINK_STATE_MASK		(0x3f << 16)
> +#define PCIE_PL_PFLR_FORCE_LINK			(1 << 15)
>  #define PCIE_PHY_DEBUG_R0 (PL_OFFSET + 0x28)  #define PCIE_PHY_DEBUG_R1
> (PL_OFFSET + 0x2c)
>  #define PCIE_PHY_DEBUG_R1_XMLH_LINK_IN_TRAINING	(1 << 29)
> @@ -214,7 +217,15 @@ static int imx6q_pcie_abort_handler(unsigned long addr,
> static int imx6_pcie_assert_core_reset(struct pcie_port *pp)  {
>  	struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
> +	u32 val;
> +
> +	val = readl(pp->dbi_base + PCIE_PL_PFLR);
> +	val &= ~PCIE_PL_PFLR_LINK_STATE_MASK;
> +	val |= PCIE_PL_PFLR_FORCE_LINK;
> +	writel(val, pp->dbi_base + PCIE_PL_PFLR);
[Richard] At this point, the port logic register access are relied on the
pcie clks enable in uboot. Otherwise, kernel would be hang, if the pcie is not enabled
in uboot ever.
> 
> +	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR12,
> +			IMX6Q_GPR12_PCIE_CTL_2, 0 << 10);
>  	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
>  			IMX6Q_GPR1_PCIE_TEST_PD, 1 << 18);
>  	regmap_update_bits(imx6_pcie->iomuxc_gpr, IOMUXC_GPR1,
> --
> 2.0.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in the
> body of a message to majordomo at vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html

^ permalink raw reply

* [[RFC PATCH]] gpio: gpio-mxc: make sure gpio is input when request IRQ
From: Markus Niebel @ 2014-07-22  7:19 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20140722062803.GA21229@dragon>

Am 22.07.2014 08:28, wrote Shawn Guo:
> On Wed, Jul 16, 2014 at 03:51:04PM +0200, Markus Niebel wrote:
>> From: Markus Niebel <Markus.Niebel@tq-group.com>
>>
>> When requesting an GPIO irq for imx Soc two things are missing:
>> - there is no check, if the GPIO is already requested
>> - there is no check, if the GPIO is configured as input
>>
>> The first case can lead to reconfiguring the GPIO pin from third
>> party while it is used as IRQ pin, second case will (eventually)
>> prevent IRQ from being seen by SOC becaus the pin is driven by
>> Soc
>>
>> This patch tries to implement (logic taken roughly from gpio-omap)
>> - basic check if gpio already requested
>> - if needed requests the gpio and configures as IN.
>> - if gpio is already requested it is only verified if pin is IN
>> - gpio is locked as irq
>>
>> Tested on a not mainlined i.MX6 based hardware with pin configured
>> by bootloader as OUT HIGH and expecting a low active IRQ.
>>
>> Signed-off-by: Markus Niebel <Markus.Niebel@tq-group.com>
>> ---
>>  drivers/gpio/gpio-mxc.c |   35 +++++++++++++++++++++++++++++++++++
>>  1 file changed, 35 insertions(+)
>>
>> diff --git a/drivers/gpio/gpio-mxc.c b/drivers/gpio/gpio-mxc.c
>> index db83b3c..4316a38 100644
>> --- a/drivers/gpio/gpio-mxc.c
>> +++ b/drivers/gpio/gpio-mxc.c
>> @@ -175,6 +175,31 @@ static int gpio_set_irq_type(struct irq_data *d, u32 type)
>>  	u32 gpio = port->bgc.gc.base + gpio_idx;
>>  	int edge;
>>  	void __iomem *reg = port->base;
>> +	int ret = 0;
>> +
>> +	if (!gpiochip_is_requested(&port->bgc.gc, gpio_idx)) {
>> +		char label[32];
>> +
>> +		snprintf(label, 32, "gpio%u-irq", gpio);
>> +		ret = gpio_request_one(gpio, GPIOF_DIR_IN, label);
> 
> I'm not sure it's correct to call gpio_request_one() from .set_irq_type
> hook.  It looks like a API usage violation to me.  It should really be
> called from client driver.

Thats why it is an RFC. I add Linus Walleij to the cc-list.

Let me describe the problem:

Currently client drivers have simply interrupts and interrupt-parent
in their bindings, but no interrupt-gpios. Therefore in this case a
client does not know about a dedicated gpio which is to be requested
and configured.

> 
>> +	} else {
>> +		val = readl(port->base + GPIO_GDIR);
>> +		if (val & BIT(gpio_idx))
>> +			ret = -EINVAL;
> 
> It says that the GPIO is requested by someone, but we're not really sure
> if it's the correct one, i.e. the one is requesting set_irq_type.
> 

Yes, but the current situation is even worse (in my eyes): an IRQ can be requested and an
independend party can request and configure the gpio as output ...

>> +	}
>> +
>> +	if (ret) {
>> +		dev_err(port->bgc.gc.dev, "unable to set gpio_idx %u as IN\n",
>> +			gpio_idx);
>> +		return ret;
>> +	}
> 
> Having said that, I'm not sure any above changes is really necessary.
> If any, I would say only gpiochip_is_requested() check makes some sense,
> but we should just fail out if the GPIO hasn't been requested.  Nothing
> more can be done in there.

Going that way as a consequence a reworked device tree binding for gpio irq is needed
(just like in the platform data days) when providing a gpio number and the client has
to request gpio and irq - correct me if I'm wrong.

Maybe here is something needed with deeper knowledge in the gpio subsystem.

> 
>> +
>> +	ret = gpio_lock_as_irq(&port->bgc.gc, gpio_idx);
>> +	if (ret) {
>> +		dev_err(port->bgc.gc.dev, "unable to lock gpio_idx %u for IRQ\n",
>> +			gpio_idx);
>> +		return ret;
>> +	}
> 
> This and the following changes do make sense to me.
> 
> Shawn
> 
>>  
>>  	port->both_edges &= ~(1 << gpio_idx);
>>  	switch (type) {
>> @@ -231,6 +256,15 @@ static int gpio_set_irq_type(struct irq_data *d, u32 type)
>>  	return 0;
>>  }
>>  
>> +static void gpio_irq_shutdown(struct irq_data *d)
>> +{
>> +	struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
>> +	struct mxc_gpio_port *port = gc->private;
>> +	u32 gpio_idx = d->hwirq;
>> +
>> +	gpio_unlock_as_irq(&port->bgc.gc, gpio_idx);
>> +}
>> +
>>  static void mxc_flip_edge(struct mxc_gpio_port *port, u32 gpio)
>>  {
>>  	void __iomem *reg = port->base;
>> @@ -353,6 +387,7 @@ static void __init mxc_gpio_init_gc(struct mxc_gpio_port *port, int irq_base)
>>  	ct->chip.irq_mask = irq_gc_mask_clr_bit;
>>  	ct->chip.irq_unmask = irq_gc_mask_set_bit;
>>  	ct->chip.irq_set_type = gpio_set_irq_type;
>> +	ct->chip.irq_shutdown = gpio_irq_shutdown;
>>  	ct->chip.irq_set_wake = gpio_set_wake_irq;
>>  	ct->regs.ack = GPIO_ISR;
>>  	ct->regs.mask = GPIO_IMR;
>> -- 
>> 1.7.9.5
>>
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

^ permalink raw reply

* [RFC V2] devicetree: Dialog Semiconductor consolidate existing vendor prefixes to standardise on 'dlg'
From: Lee Jones @ 2014-07-22  7:09 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <201407151520.s6FFKcjB009745@swsrvapps-01.diasemi.com>

On Tue, 15 Jul 2014, Opensource [Steve Twiss] wrote:

> From: Opensource [Steve Twiss] <stwiss.opensource@diasemi.com>
> 
> This patch series updates the device tree vendor prefix for
> Dialog Semiconductor.
> 
> Various methods are currently used throughout the kernel: 'diasemi',
> 'dialog' and 'dlg'. Others have also been suggested.
> 
> This patch set aims to consolidate the usage of the vendor prefix to
> use a common standard. The prefix 'dlg' is used.
> 
> Here is my working for justifying this change:
> 
> ./arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi
> 	Has the following entry:
> 	compatible = "dialog,da9063";
> 	However the DA9063 driver does not support device tree yet so
> 	it would be safe to rename this.
> 
> ./arch/arm/boot/dts/imx53-smd.dts
> 	Has the following entry:
> 	compatible = "dialog,da9053", "dialog,da9052";
> 	However, the existing driver files for DA9053 define a different
> 	compatible string with the "dlg" prefix. See the entries below.
> 	None of these would have allowed the "dialog" prefix.
> 	{ .compatible = "dlg,da9052", .data = &da9052_i2c_id[0] },
> 	{ .compatible = "dlg,da9053-aa", .data = &da9052_i2c_id[1] },
> 	{ .compatible = "dlg,da9053-ba", .data = &da9052_i2c_id[2] },
> 	{ .compatible = "dlg,da9053-bb", .data = &da9052_i2c_id[3] },
> 	{ .compatible = "dlg,da9053-bc", .data = &da9052_i2c_id[4] },
> 	In this particular case the change for DA9053 did not match up
> 	with the expected compatibility strings and therefore I have
> 	retained the more general "dlg,da9053" because I do not know
> 	which silicon variant (-aa, -ba, -bb, or -bc) is the correct
> 	one to use.
> 
> ./devicetree/bindings/i2c/trivial-devices.txt
> 	Has the following entry:
> 	dialog,da9053  DA9053: flexible system level PMIC with multicore support
> 	Instead of depreciating this "dialog" line I am just replacing it
> 	with a "dlg" because the existing driver DA9053 does not support
> 	the dialog keyword.
> 
> ./drivers/mfd/da9055-core.c
> 	Has the following entries for the mfd cells 
> 		.of_compatible = "dialog,da9055-gpio", etc...
> 	In this case, the driver does not actually pass in any platform data
> 	to any of the mfd cells and so they are not actually used
> 	yet in the driver. Nobody else references this information.
> 
> ./devicetree/bindings/regulator/da9210.txt
> 	Has the following two entries in the binding file:
> 	- compatible:	must be "diasemi,da9210"
> 	compatible = "diasemi,da9210";
> 	However the DA9210 driver does not support device tree.
> 
> ./arch/arm/boot/dts/r8a7790-lager.dts
> ./arch/arm/boot/dts/r8a7791-koelsch.dts
> 	These two files have the following entries:
> 	compatible = "diasemi,da9210";
> 	These both reference the "diasemi,da9210" but the device
> 	driver does not support device tree
> 
> The remaining files in the kernel I have found correctly references
> the driver files compatibility information and so did not need to
> be changed.
> 
> ./devicetree/bindings/mfd/da9052-i2c.txt
> 	- compatible : Should be "dlg,da9052", "dlg,da9053-aa",
> 		 "dlg,da9053-ab", or "dlg,da9053-bb"
> 
> ./devicetree/bindings/mfd/da9055.txt
> 	compatible = "dlg,da9055-pmic";
> 
> ./arch/arm/boot/dts/imx53-voipac-dmm-668.dtsi
> 	compatible = "dlg,da9053-aa", "dlg,da9052";
> 
> ./arch/arm/boot/dts/imx53-qsb.dts
> 	compatible = "dlg,da9053-aa", "dlg,da9052";
> 
> ./devicetree/bindings/sound/da9055.txt
> 	- compatible: "dlg,da9055-codec"
> 	compatible = "dlg,da9055-codec";
> 
> 
> Signed-off-by: Opensource [Steve Twiss] <stwiss.opensource@diasemi.com>
> ---
> Checks performed with linux-next/next-20140715/scripts/checkpatch.pl
>  trivial-devices.txt       total: 0 errors, 0 warnings, 89 lines checked
>  da9210.txt                total: 0 errors, 0 warnings, 21 lines checked
>  vendor-prefixes.txt       total: 0 errors, 0 warnings, 149 lines checked
>  imx53-smd.dts             total: 0 errors, 2 warnings, 279 lines checked
>  imx6qdl-phytec-pfla02.dtsi total: 0 errors, 2 warnings, 357 lines checked
>  r8a7790-lager.dts         total: 0 errors, 3 warnings, 403 lines checked
>  r8a7791-koelsch.dts       total: 0 errors, 4 warnings, 461 lines checked
>  da9055-core.c             total: 0 errors, 0 warnings, 428 lines checked
> 
> This e-mail is in response to the previous threads here:
> https://lkml.org/lkml/2014/6/11/262
> http://comments.gmane.org/gmane.linux.ports.arm.kernel/341358
> 
> Changes since RFC V1
> - addition of changes to DTS files referencing "diasemi,da9210"
>    arch/arm/boot/dts/r8a7790-lager.dts
>    arch/arm/boot/dts/r8a7791-koelsch.dts
> 
> This RFC V2 does not answer the response to RFC V1 from Mark Brown:
> http://www.spinics.net/lists/arm-kernel/msg347615.html
> 
> This patch applies against linux-next and next-20140715 
> 
> Regards,
> Steve Twiss, Dialog Semiconductor Ltd.
> 
> 
> 
>  .../devicetree/bindings/i2c/trivial-devices.txt    |  2 +-
>  .../devicetree/bindings/regulator/da9210.txt       |  4 ++--
>  .../devicetree/bindings/vendor-prefixes.txt        |  1 +
>  arch/arm/boot/dts/imx53-smd.dts                    |  2 +-
>  arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi       |  2 +-
>  arch/arm/boot/dts/r8a7790-lager.dts                |  2 +-
>  arch/arm/boot/dts/r8a7791-koelsch.dts              |  2 +-
>  drivers/mfd/da9055-core.c                          | 26 ++++++++++----------

For the MFD changes:

  Acked-by: Lee Jones <lee.jones@linaro.org>

Which tree is this patch going into?  Do you want me to take it and
supply an IB for the other Maintainers to pull from?

>  8 files changed, 21 insertions(+), 20 deletions(-)

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

^ permalink raw reply

* [PATCH 2/6] ARM: imx: clk-vf610: add USBPHY clocks
From: Jingchang Lu @ 2014-07-22  6:58 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20140722023205.GS8537@dragon>


>-----Original Message-----
>From: Shawn Guo [mailto:shawn.guo at freescale.com]
>Sent: Tuesday, July 22, 2014 10:32 AM
>To: Stefan Agner; Lu Jingchang-B35083
>Cc: Chen Peter-B29397; s.hauer at pengutronix.de; linux-arm-
>kernel at lists.infradead.org; linux-usb at vger.kernel.org; linux-
>kernel at vger.kernel.org
>Subject: Re: [PATCH 2/6] ARM: imx: clk-vf610: add USBPHY clocks
>
>On Fri, Jul 18, 2014 at 07:01:38PM +0200, Stefan Agner wrote:
>> This commit adds PLL7 which is required for USBPHY1. It also adds the
>> USB PHY and USB Controller clocks and the gates to enable them.
>>
>> Signed-off-by: Stefan Agner <stefan@agner.ch>
>
>Jingchang,
>
>Does the patch look good to you?
>
>Shawn
>
For the clk creation, I think it is ok if the functionality has been tested, thanks!

Acked-by: Jingchang Lu <jingchang.lu@freescale.com>

^ permalink raw reply

* [PATCH V2 1/2] ARM: OMAP2+: DMA: remove requirement of irq for platform-dma driver
From: Tony Lindgren @ 2014-07-22  6:37 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1402573523-13814-2-git-send-email-r.sricharan@ti.com>

* Sricharan R <r.sricharan@ti.com> [140612 04:48]:
> From: Nishanth Menon <nm@ti.com>
> 
> we have currently 2 DMA drivers that try to co-exist.
> drivers/dma/omap-dma.c which registers it's own IRQ and is device tree
> aware and uses arch/arm/plat-omap/dma.c instance created by
> arch/arm/mach-omap2/dma.c to maintain channel usage (omap_request_dma).
> 
> Currently both try to register interrupts and mach-omap2/plat-omap dma.c
> attempts to use the IRQ number registered by hwmod to register it's own
> interrupt handler.
> 
> Now, there is no reasonable way of static allocating DMA irq in GIC
> SPI when we use crossbar. However, since the dma_chan structure is
> freed as a result of IRQ not being present due to devm allocation,
> maintaining information of channel by platform code fails at a later
> point in time when that region of memory is reused.
> 
> So, if hwmod does not indicate an IRQ number, then, assume that
> dma-engine will take care of the interrupt handling.

Looks OK to me, applying both into omap-for-v3.17/soc thanks.

Regards,

Tony

^ permalink raw reply

* [PATCH] SPI: spi-imx: enable realtime master workqueue
From: Shawn Guo @ 2014-07-22  6:35 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1405683059-23316-1-git-send-email-list-09_linux_arm@tqsc.de>

On Fri, Jul 18, 2014 at 01:30:59PM +0200, Markus Niebel wrote:
> From: Markus Niebel <Markus.Niebel@tq-group.de>
> 
> SPI master provides an option to run the SPI workqueue
> with realtime prio. This feature is currently used only
> by spi-pl022.
> 
> Support this feature for spi-imx by parsing an optional
> bool value from device tree.

This sounds like a Linux specific feature/implementation, so shouldn't
be a decision of device tree.

Shawn

> 
> Note: maybe useful for all SPI controllers.
> 
> Signed-off-by: Markus Niebel <Markus.Niebel@tq-group.de>
> ---
>  .../devicetree/bindings/spi/fsl-imx-cspi.txt       |    4 ++++
>  drivers/spi/spi-imx.c                              |    1 +
>  2 files changed, 5 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
> index 4256a6d..6b908c7 100644
> --- a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
> +++ b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt
> @@ -8,6 +8,10 @@ Required properties:
>  - fsl,spi-num-chipselects : Contains the number of the chipselect
>  - cs-gpios : Specifies the gpio pins to be used for chipselects.
>  
> +Optional properties:
> +- fsl,rt : indicates the controller should run the message pump with realtime
> +	   priority to minimise the transfer latency on the bus (boolean)
> +
>  Example:
>  
>  ecspi at 70010000 {
> diff --git a/drivers/spi/spi-imx.c b/drivers/spi/spi-imx.c
> index 5daff20..3a9c373 100644
> --- a/drivers/spi/spi-imx.c
> +++ b/drivers/spi/spi-imx.c
> @@ -835,6 +835,7 @@ static int spi_imx_probe(struct platform_device *pdev)
>  	master->bits_per_word_mask = SPI_BPW_RANGE_MASK(1, 32);
>  	master->bus_num = pdev->id;
>  	master->num_chipselect = num_cs;
> +	master->rt = of_property_read_bool(np, "fsl,rt");
>  
>  	spi_imx = spi_master_get_devdata(master);
>  	spi_imx->bitbang.master = master;
> -- 
> 1.7.9.5
> 

^ permalink raw reply

* [[RFC PATCH]] gpio: gpio-mxc: make sure gpio is input when request IRQ
From: Shawn Guo @ 2014-07-22  6:28 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1405518664-31313-1-git-send-email-list-09_linux_arm@tqsc.de>

On Wed, Jul 16, 2014 at 03:51:04PM +0200, Markus Niebel wrote:
> From: Markus Niebel <Markus.Niebel@tq-group.com>
> 
> When requesting an GPIO irq for imx Soc two things are missing:
> - there is no check, if the GPIO is already requested
> - there is no check, if the GPIO is configured as input
> 
> The first case can lead to reconfiguring the GPIO pin from third
> party while it is used as IRQ pin, second case will (eventually)
> prevent IRQ from being seen by SOC becaus the pin is driven by
> Soc
> 
> This patch tries to implement (logic taken roughly from gpio-omap)
> - basic check if gpio already requested
> - if needed requests the gpio and configures as IN.
> - if gpio is already requested it is only verified if pin is IN
> - gpio is locked as irq
> 
> Tested on a not mainlined i.MX6 based hardware with pin configured
> by bootloader as OUT HIGH and expecting a low active IRQ.
> 
> Signed-off-by: Markus Niebel <Markus.Niebel@tq-group.com>
> ---
>  drivers/gpio/gpio-mxc.c |   35 +++++++++++++++++++++++++++++++++++
>  1 file changed, 35 insertions(+)
> 
> diff --git a/drivers/gpio/gpio-mxc.c b/drivers/gpio/gpio-mxc.c
> index db83b3c..4316a38 100644
> --- a/drivers/gpio/gpio-mxc.c
> +++ b/drivers/gpio/gpio-mxc.c
> @@ -175,6 +175,31 @@ static int gpio_set_irq_type(struct irq_data *d, u32 type)
>  	u32 gpio = port->bgc.gc.base + gpio_idx;
>  	int edge;
>  	void __iomem *reg = port->base;
> +	int ret = 0;
> +
> +	if (!gpiochip_is_requested(&port->bgc.gc, gpio_idx)) {
> +		char label[32];
> +
> +		snprintf(label, 32, "gpio%u-irq", gpio);
> +		ret = gpio_request_one(gpio, GPIOF_DIR_IN, label);

I'm not sure it's correct to call gpio_request_one() from .set_irq_type
hook.  It looks like a API usage violation to me.  It should really be
called from client driver.

> +	} else {
> +		val = readl(port->base + GPIO_GDIR);
> +		if (val & BIT(gpio_idx))
> +			ret = -EINVAL;

It says that the GPIO is requested by someone, but we're not really sure
if it's the correct one, i.e. the one is requesting set_irq_type.

> +	}
> +
> +	if (ret) {
> +		dev_err(port->bgc.gc.dev, "unable to set gpio_idx %u as IN\n",
> +			gpio_idx);
> +		return ret;
> +	}

Having said that, I'm not sure any above changes is really necessary.
If any, I would say only gpiochip_is_requested() check makes some sense,
but we should just fail out if the GPIO hasn't been requested.  Nothing
more can be done in there.

> +
> +	ret = gpio_lock_as_irq(&port->bgc.gc, gpio_idx);
> +	if (ret) {
> +		dev_err(port->bgc.gc.dev, "unable to lock gpio_idx %u for IRQ\n",
> +			gpio_idx);
> +		return ret;
> +	}

This and the following changes do make sense to me.

Shawn

>  
>  	port->both_edges &= ~(1 << gpio_idx);
>  	switch (type) {
> @@ -231,6 +256,15 @@ static int gpio_set_irq_type(struct irq_data *d, u32 type)
>  	return 0;
>  }
>  
> +static void gpio_irq_shutdown(struct irq_data *d)
> +{
> +	struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
> +	struct mxc_gpio_port *port = gc->private;
> +	u32 gpio_idx = d->hwirq;
> +
> +	gpio_unlock_as_irq(&port->bgc.gc, gpio_idx);
> +}
> +
>  static void mxc_flip_edge(struct mxc_gpio_port *port, u32 gpio)
>  {
>  	void __iomem *reg = port->base;
> @@ -353,6 +387,7 @@ static void __init mxc_gpio_init_gc(struct mxc_gpio_port *port, int irq_base)
>  	ct->chip.irq_mask = irq_gc_mask_clr_bit;
>  	ct->chip.irq_unmask = irq_gc_mask_set_bit;
>  	ct->chip.irq_set_type = gpio_set_irq_type;
> +	ct->chip.irq_shutdown = gpio_irq_shutdown;
>  	ct->chip.irq_set_wake = gpio_set_wake_irq;
>  	ct->regs.ack = GPIO_ISR;
>  	ct->regs.mask = GPIO_IMR;
> -- 
> 1.7.9.5
> 

^ permalink raw reply

* [PATCH 1/7] arm: dts: omap3-gta04: Add nand support
From: Tony Lindgren @ 2014-07-22  6:24 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1405976727-15166-2-git-send-email-marek@goldelico.com>

* Marek Belisko <marek@goldelico.com> [140721 14:08]:

Can you please add the descriptions to all the patches?
Other than that looks OK to me.

Regards,

Tony

^ permalink raw reply

* [PATCH v2 0/3] iommu: Remove OMAP IOVMM driver
From: Tony Lindgren @ 2014-07-22  6:19 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <5717663.qOZzl7syrN@avalon>

* Laurent Pinchart <laurent.pinchart@ideasonboard.com> [140721 11:17]:
> Hi Tony and Joerg,
> 
> On Monday 21 July 2014 02:33:36 Tony Lindgren wrote:
> > * Laurent Pinchart <laurent.pinchart@ideasonboard.com> [140721 02:16]:
> > > Hi Suman, Joerg and Tony,
> > > 
> > > On Friday 18 July 2014 11:53:56 Suman Anna wrote:
> > > > On 07/18/2014 05:49 AM, Laurent Pinchart wrote:
> > > > > Hello,
> > > > > 
> > > > > The OMAP3 ISP driver was the only user of the OMAP IOVMM API. Now that
> > > > > is has been ported to the DMA API, remove the unused virtual memory
> > > > > manager.
> > > > > 
> > > > > The removal is split in three patches to ease upstream merge. The
> > > > > first patch removes the omap-iovmm driver, the second patch removes
> > > > > setting of now unused platform data fields from arch code, and the
> > > > > last patch cleans up the platform data structure.
> > > > 
> > > > Thanks for the revised series, it looks good. I have also tested the
> > > > series on OMAP3, OMAP4 and OMAP5.
> > > > 
> > > > For the changes in the entire series,
> > > > Acked-by: Suman Anna <s-anna@ti.com>
> > > 
> > > Thank you.
> > > 
> > > > > I'd like to get at least the first patch merged in v3.17. To avoid
> > > > > splitting the series across three kernel versions, it would be nice to
> > > > > also merge at least the second patch for v3.17. If there's no risk of
> > > > > conflict everything could be merged in one go through the ARM SoC
> > > > > tree. Otherwise a stable branch with patch 1/3 will be needed to base
> > > > > the arch change on.
> > > > > 
> > > > > Joerg, Tony, how would you like to proceed ?
> > > 
> > > The v3.17 merge window is getting close, it's probably too late to merge
> > > patch 2/3. Joerg, could you please take 1/3 in your tree for v3.17 ? 2/3
> > > and 3/3 would then get in v3.18. Tony, how would you like to proceed for
> > > those ?
> >
> > How about Joerg maybe do an immutable branch against v3.16-rc1
> > with just these three patches and merge it into your tree?
> > 
> > That way I too can merge the minimal branch in if there are conflics.
> > If that works for Joerg, then for arch/arm/*omap* changes:
> > 
> > Acked-by: Tony Lindgren <tony@atomide.com>
> 
> I've created an immutable branch (or, rather, immutable until the changes 
> reach mainline, at which point I will remove the branch) on top of v3.16-rc1 
> with just the three patches from this series. You can find it at.
> 
> 	git://linuxtv.org/pinchartl/media.git omap/iommu
> 
> Tony, is there still time to get this (and especially patch 2/3, which touches 
> arch/ code) in v3.17 ?

Yes as long as Joerg is OK to merge that branch in :)

Regards,

Tony

^ permalink raw reply

* [RESEND PATCH] thermal: samsung: Add TMU support for Exynos3250 SoC
From: amit daniel kachhap @ 2014-07-22  6:11 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1405922696.2455.1.camel@rzhang1-toshiba>

On Mon, Jul 21, 2014 at 11:34 AM, Zhang Rui <rui.zhang@intel.com> wrote:
> On Fri, 2014-07-18 at 09:00 +0900, Chanwoo Choi wrote:
>> This patch adds the registers, bit fields and compatible strings
>> required to support for the 1 TMU channels on Exynos3250.
>>
>> Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
>> [Add MUX address setting bits by Jonghwa Lee]
>> Signed-off-by: Jonghwa Lee <jonghwa3.lee@samsung.com>
>> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
>> Reviewed-by: Amit Daniel Kachhap<amit.daniel@samsung.com>
>
> Eduardo and Amit,
>
> do you have any comments on this?
The changes looks fine to me. I already reviewed these patches earlier.

thanks,
Amit
>
> thanks,
> rui
>
>> ---
>>  .../devicetree/bindings/thermal/exynos-thermal.txt |  1 +
>>  drivers/thermal/samsung/exynos_tmu.c               |  7 +-
>>  drivers/thermal/samsung/exynos_tmu.h               |  3 +-
>>  drivers/thermal/samsung/exynos_tmu_data.c          | 89 ++++++++++++++++++++++
>>  drivers/thermal/samsung/exynos_tmu_data.h          |  7 ++
>>  5 files changed, 105 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> index c949092..ae738f5 100644
>> --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> +++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
>> @@ -3,6 +3,7 @@
>>  ** Required properties:
>>
>>  - compatible : One of the following:
>> +            "samsung,exynos3250-tmu"
>>              "samsung,exynos4412-tmu"
>>              "samsung,exynos4210-tmu"
>>              "samsung,exynos5250-tmu"
>> diff --git a/drivers/thermal/samsung/exynos_tmu.c b/drivers/thermal/samsung/exynos_tmu.c
>> index d7ca9f4..a2a08ea 100644
>> --- a/drivers/thermal/samsung/exynos_tmu.c
>> +++ b/drivers/thermal/samsung/exynos_tmu.c
>> @@ -505,6 +505,10 @@ static irqreturn_t exynos_tmu_irq(int irq, void *id)
>>
>>  static const struct of_device_id exynos_tmu_match[] = {
>>       {
>> +             .compatible = "samsung,exynos3250-tmu",
>> +             .data = (void *)EXYNOS3250_TMU_DRV_DATA,
>> +     },
>> +     {
>>               .compatible = "samsung,exynos4210-tmu",
>>               .data = (void *)EXYNOS4210_TMU_DRV_DATA,
>>       },
>> @@ -677,7 +681,8 @@ static int exynos_tmu_probe(struct platform_device *pdev)
>>               goto err_clk_sec;
>>       }
>>
>> -     if (pdata->type == SOC_ARCH_EXYNOS4210 ||
>> +     if (pdata->type == SOC_ARCH_EXYNOS3250 ||
>> +         pdata->type == SOC_ARCH_EXYNOS4210 ||
>>           pdata->type == SOC_ARCH_EXYNOS4412 ||
>>           pdata->type == SOC_ARCH_EXYNOS5250 ||
>>           pdata->type == SOC_ARCH_EXYNOS5260 ||
>> diff --git a/drivers/thermal/samsung/exynos_tmu.h b/drivers/thermal/samsung/exynos_tmu.h
>> index edd08cf..1b4a644 100644
>> --- a/drivers/thermal/samsung/exynos_tmu.h
>> +++ b/drivers/thermal/samsung/exynos_tmu.h
>> @@ -40,7 +40,8 @@ enum calibration_mode {
>>  };
>>
>>  enum soc_type {
>> -     SOC_ARCH_EXYNOS4210 = 1,
>> +     SOC_ARCH_EXYNOS3250 = 1,
>> +     SOC_ARCH_EXYNOS4210,
>>       SOC_ARCH_EXYNOS4412,
>>       SOC_ARCH_EXYNOS5250,
>>       SOC_ARCH_EXYNOS5260,
>> diff --git a/drivers/thermal/samsung/exynos_tmu_data.c b/drivers/thermal/samsung/exynos_tmu_data.c
>> index c1d81dc..aa8e0de 100644
>> --- a/drivers/thermal/samsung/exynos_tmu_data.c
>> +++ b/drivers/thermal/samsung/exynos_tmu_data.c
>> @@ -90,6 +90,95 @@ struct exynos_tmu_init_data const exynos4210_default_tmu_data = {
>>  };
>>  #endif
>>
>> +#if defined(CONFIG_SOC_EXYNOS3250)
>> +static const struct exynos_tmu_registers exynos3250_tmu_registers = {
>> +     .triminfo_data = EXYNOS_TMU_REG_TRIMINFO,
>> +     .triminfo_25_shift = EXYNOS_TRIMINFO_25_SHIFT,
>> +     .triminfo_85_shift = EXYNOS_TRIMINFO_85_SHIFT,
>> +     .tmu_ctrl = EXYNOS_TMU_REG_CONTROL,
>> +     .test_mux_addr_shift = EXYNOS4412_MUX_ADDR_SHIFT,
>> +     .buf_vref_sel_shift = EXYNOS_TMU_REF_VOLTAGE_SHIFT,
>> +     .buf_vref_sel_mask = EXYNOS_TMU_REF_VOLTAGE_MASK,
>> +     .therm_trip_mode_shift = EXYNOS_TMU_TRIP_MODE_SHIFT,
>> +     .therm_trip_mode_mask = EXYNOS_TMU_TRIP_MODE_MASK,
>> +     .therm_trip_en_shift = EXYNOS_TMU_THERM_TRIP_EN_SHIFT,
>> +     .buf_slope_sel_shift = EXYNOS_TMU_BUF_SLOPE_SEL_SHIFT,
>> +     .buf_slope_sel_mask = EXYNOS_TMU_BUF_SLOPE_SEL_MASK,
>> +     .core_en_shift = EXYNOS_TMU_CORE_EN_SHIFT,
>> +     .tmu_status = EXYNOS_TMU_REG_STATUS,
>> +     .tmu_cur_temp = EXYNOS_TMU_REG_CURRENT_TEMP,
>> +     .threshold_th0 = EXYNOS_THD_TEMP_RISE,
>> +     .threshold_th1 = EXYNOS_THD_TEMP_FALL,
>> +     .tmu_inten = EXYNOS_TMU_REG_INTEN,
>> +     .inten_rise0_shift = EXYNOS_TMU_INTEN_RISE0_SHIFT,
>> +     .inten_rise1_shift = EXYNOS_TMU_INTEN_RISE1_SHIFT,
>> +     .inten_rise2_shift = EXYNOS_TMU_INTEN_RISE2_SHIFT,
>> +     .inten_fall0_shift = EXYNOS_TMU_INTEN_FALL0_SHIFT,
>> +     .tmu_intstat = EXYNOS_TMU_REG_INTSTAT,
>> +     .tmu_intclear = EXYNOS_TMU_REG_INTCLEAR,
>> +     .intclr_fall_shift = EXYNOS_TMU_CLEAR_FALL_INT_SHIFT,
>> +     .intclr_rise_shift = EXYNOS_TMU_RISE_INT_SHIFT,
>> +     .intclr_rise_mask = EXYNOS_TMU_RISE_INT_MASK,
>> +     .intclr_fall_mask = EXYNOS_TMU_FALL_INT_MASK,
>> +     .emul_con = EXYNOS_EMUL_CON,
>> +     .emul_temp_shift = EXYNOS_EMUL_DATA_SHIFT,
>> +     .emul_time_shift = EXYNOS_EMUL_TIME_SHIFT,
>> +     .emul_time_mask = EXYNOS_EMUL_TIME_MASK,
>> +};
>> +
>> +#define EXYNOS3250_TMU_DATA \
>> +     .threshold_falling = 10, \
>> +     .trigger_levels[0] = 70, \
>> +     .trigger_levels[1] = 95, \
>> +     .trigger_levels[2] = 110, \
>> +     .trigger_levels[3] = 120, \
>> +     .trigger_enable[0] = true, \
>> +     .trigger_enable[1] = true, \
>> +     .trigger_enable[2] = true, \
>> +     .trigger_enable[3] = false, \
>> +     .trigger_type[0] = THROTTLE_ACTIVE, \
>> +     .trigger_type[1] = THROTTLE_ACTIVE, \
>> +     .trigger_type[2] = SW_TRIP, \
>> +     .trigger_type[3] = HW_TRIP, \
>> +     .max_trigger_level = 4, \
>> +     .gain = 8, \
>> +     .reference_voltage = 16, \
>> +     .noise_cancel_mode = 4, \
>> +     .cal_type = TYPE_TWO_POINT_TRIMMING, \
>> +     .efuse_value = 55, \
>> +     .min_efuse_value = 40, \
>> +     .max_efuse_value = 100, \
>> +     .first_point_trim = 25, \
>> +     .second_point_trim = 85, \
>> +     .default_temp_offset = 50, \
>> +     .freq_tab[0] = { \
>> +             .freq_clip_max = 800 * 1000, \
>> +             .temp_level = 70, \
>> +     }, \
>> +     .freq_tab[1] = { \
>> +             .freq_clip_max = 400 * 1000, \
>> +             .temp_level = 95, \
>> +     }, \
>> +     .freq_tab_count = 2, \
>> +     .registers = &exynos3250_tmu_registers, \
>> +     .features = (TMU_SUPPORT_EMULATION | \
>> +                     TMU_SUPPORT_FALLING_TRIP | TMU_SUPPORT_READY_STATUS | \
>> +                     TMU_SUPPORT_EMUL_TIME)
>> +#endif
>> +
>> +#if defined(CONFIG_SOC_EXYNOS3250)
>> +struct exynos_tmu_init_data const exynos3250_default_tmu_data = {
>> +     .tmu_data = {
>> +             {
>> +                     EXYNOS3250_TMU_DATA,
>> +                     .type = SOC_ARCH_EXYNOS3250,
>> +                     .test_mux = EXYNOS4412_MUX_ADDR_VALUE,
>> +             },
>> +     },
>> +     .tmu_count = 1,
>> +};
>> +#endif
>> +
>>  #if defined(CONFIG_SOC_EXYNOS4412) || defined(CONFIG_SOC_EXYNOS5250)
>>  static const struct exynos_tmu_registers exynos4412_tmu_registers = {
>>       .triminfo_data = EXYNOS_TMU_REG_TRIMINFO,
>> diff --git a/drivers/thermal/samsung/exynos_tmu_data.h b/drivers/thermal/samsung/exynos_tmu_data.h
>> index d268981..f0979e5 100644
>> --- a/drivers/thermal/samsung/exynos_tmu_data.h
>> +++ b/drivers/thermal/samsung/exynos_tmu_data.h
>> @@ -148,6 +148,13 @@
>>  #define EXYNOS5440_TMU_TH_RISE4_SHIFT                24
>>  #define EXYNOS5440_EFUSE_SWAP_OFFSET         8
>>
>> +#if defined(CONFIG_SOC_EXYNOS3250)
>> +extern struct exynos_tmu_init_data const exynos3250_default_tmu_data;
>> +#define EXYNOS3250_TMU_DRV_DATA (&exynos3250_default_tmu_data)
>> +#else
>> +#define EXYNOS3250_TMU_DRV_DATA (NULL)
>> +#endif
>> +
>>  #if defined(CONFIG_CPU_EXYNOS4210)
>>  extern struct exynos_tmu_init_data const exynos4210_default_tmu_data;
>>  #define EXYNOS4210_TMU_DRV_DATA (&exynos4210_default_tmu_data)
>
>
>
> _______________________________________________
> 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 RESEND] drm/ttm: expose CPU address of DMA-allocated pages
From: Alexandre Courbot @ 2014-07-22  5:46 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <CAPM=9txDw7fJpeFB72OdSgAVuaZbpfivV-9imT9V1MBYDvBv-A@mail.gmail.com>

On Tue, Jul 22, 2014 at 2:07 PM, Dave Airlie <airlied@gmail.com> wrote:
> On 22 July 2014 14:21, Alexandre Courbot <gnurou@gmail.com> wrote:
>> DRM maintainers, could I have a comment about this patch? A bunch of
>> Nouveau changes depend on it.
>
> I'm not sure we really have anyone who is in a great position to comment,
>
> my major issue would be its allocate a large chunk of RAM that might
> not be needed
> in all cases, and if we could avoid that when we don't need it, then
> it would be good.

Strictly speaking memory allocated using dma_alloc_coherent() should
only be accessed by the CPU through the returned mapping, so having
this extra information is probably as legitimate as the current
dma_address array.

Now I agree that this results in more memory being used, which is
especially sad since this information is already known in the dma_page
internal structure. Maybe we could expose the whole dma_pages instead
of just the dma address? That way both addresses would be accessible
for the same memory cost (we will need an array to store the adresses
to the dma_pages).

>
> Or maybe we could join some allocations together, but with the Linux
> mm subsystem,
> who knows maybe separate small allocs have a better hope of success.
>
> Dave.

^ permalink raw reply

* [PATCH] ARM: dts: imx: Add alias for ethernet controller
From: Marek Vasut @ 2014-07-22  5:45 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20140722052046.GW8537@dragon>

On Tuesday, July 22, 2014 at 07:20:48 AM, Shawn Guo wrote:
> On Tue, Jul 22, 2014 at 07:00:48AM +0200, Marek Vasut wrote:
> > On Tuesday, July 22, 2014 at 05:03:38 AM, Shawn Guo wrote:
> > > On Tue, Jul 22, 2014 at 04:10:26AM +0200, Marek Vasut wrote:
> > > > On Monday, March 24, 2014 at 02:49:38 AM, Shawn Guo wrote:
> > > > > On Tue, Mar 18, 2014 at 01:37:09AM +0100, Marek Vasut wrote:
> > > > > > On Friday, February 28, 2014 at 12:58:41 PM, Marek Vasut wrote:
> > > > > > > Add alias for FEC ethernet on i.MX to allow bootloaders (like
> > > > > > > U-Boot) patch-in the MAC address for FEC using this alias.
> > > > > > > 
> > > > > > > Signed-off-by: Marek Vasut <marex@denx.de>
> > > > > > > Cc: Shawn Guo <shawn.guo@linaro.org>
> > > > > > 
> > > > > > Bump ?
> > > > > 
> > > > > Sorry.  I had actually applied the patch but forgot replying.
> > > > 
> > > > Hello Shawn,
> > > > 
> > > > I'd like to apply this patch for 3.14-stable , are you OK with this
> > > > please ? Shall I submit it ?
> > > 
> > > I do not see why this is a stable material.  But you do not need my
> > > approval to send patch for stable kernel.  The person you need to
> > > convince is Greg.
> > 
> > Without this patch, you will not get a mac address patched into the DT by
> > the bootloader. Therefore, your device will use a random mac address on
> > the network which is different on every boot. This is not a good thing,
> > don't you agree?
> 
> I agree this is not a good thing.  But it's neither a regression nor a
> critical issue as defined by stable_kernel_rules.txt.

If I cannot even properly boot from an NFS root with v3.14.y , it seems to me to 
be problem enough. Also, MAC address should be a unique identifier, if the FEC 
picks a random MAC, it will wreak havoc on the network (in the better case).

Best regards,
Marek Vasut

^ permalink raw reply

* [PATCH v2] ARM: i.MX6: add more chip revision support
From: Sascha Hauer @ 2014-07-22  5:44 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1406003574-4977-1-git-send-email-shawn.guo@freescale.com>

On Tue, Jul 22, 2014 at 12:32:54PM +0800, Shawn Guo wrote:
> From: Jason Liu <r64343@freescale.com>
> 
> Add more revision support for the new i.MX6DQ tape-out (TO1.5).  This
> TO1.5 is the Rev 1.3 as documented in i.MX6DQ data sheet, because TO1.3
> and TO1.4 are never revealed.
> 
> Signed-off-by: Jason Liu <r64343@freescale.com>
> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>

Acked-by: Sascha Hauer <s.hauer@pengutronix.de>

Sascha

> ---
> Changes since v1:
>  - Add a note in code for the numbering mismatch between code and
>    data sheet
>  - Fix a typo of tape-out in commit log
> 
>  arch/arm/mach-imx/anatop.c | 13 +++++++++++++
>  arch/arm/mach-imx/mxc.h    |  2 ++
>  2 files changed, 15 insertions(+)
> 
> diff --git a/arch/arm/mach-imx/anatop.c b/arch/arm/mach-imx/anatop.c
> index 4a40bbb46183..8259a625a920 100644
> --- a/arch/arm/mach-imx/anatop.c
> +++ b/arch/arm/mach-imx/anatop.c
> @@ -104,6 +104,19 @@ void __init imx_init_revision_from_anatop(void)
>  	case 2:
>  		revision = IMX_CHIP_REVISION_1_2;
>  		break;
> +	case 3:
> +		revision = IMX_CHIP_REVISION_1_3;
> +		break;
> +	case 4:
> +		revision = IMX_CHIP_REVISION_1_4;
> +		break;
> +	case 5:
> +		/*
> +		 * i.MX6DQ TO1.5 is defined as Rev 1.3 in Data Sheet, marked
> +		 * as 'D' in Part Number last character.
> +		 */
> +		revision = IMX_CHIP_REVISION_1_5;
> +		break;
>  	default:
>  		revision = IMX_CHIP_REVISION_UNKNOWN;
>  	}
> diff --git a/arch/arm/mach-imx/mxc.h b/arch/arm/mach-imx/mxc.h
> index a39b69ef4301..17a41ca65acf 100644
> --- a/arch/arm/mach-imx/mxc.h
> +++ b/arch/arm/mach-imx/mxc.h
> @@ -43,6 +43,8 @@
>  #define IMX_CHIP_REVISION_1_1		0x11
>  #define IMX_CHIP_REVISION_1_2		0x12
>  #define IMX_CHIP_REVISION_1_3		0x13
> +#define IMX_CHIP_REVISION_1_4		0x14
> +#define IMX_CHIP_REVISION_1_5		0x15
>  #define IMX_CHIP_REVISION_2_0		0x20
>  #define IMX_CHIP_REVISION_2_1		0x21
>  #define IMX_CHIP_REVISION_2_2		0x22
> -- 
> 1.9.1
> 
> 

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

^ permalink raw reply

* [PATCH] ARM: dts: imx: Add alias for ethernet controller
From: Shawn Guo @ 2014-07-22  5:20 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <201407220700.49046.marex@denx.de>

On Tue, Jul 22, 2014 at 07:00:48AM +0200, Marek Vasut wrote:
> On Tuesday, July 22, 2014 at 05:03:38 AM, Shawn Guo wrote:
> > On Tue, Jul 22, 2014 at 04:10:26AM +0200, Marek Vasut wrote:
> > > On Monday, March 24, 2014 at 02:49:38 AM, Shawn Guo wrote:
> > > > On Tue, Mar 18, 2014 at 01:37:09AM +0100, Marek Vasut wrote:
> > > > > On Friday, February 28, 2014 at 12:58:41 PM, Marek Vasut wrote:
> > > > > > Add alias for FEC ethernet on i.MX to allow bootloaders (like
> > > > > > U-Boot) patch-in the MAC address for FEC using this alias.
> > > > > > 
> > > > > > Signed-off-by: Marek Vasut <marex@denx.de>
> > > > > > Cc: Shawn Guo <shawn.guo@linaro.org>
> > > > > 
> > > > > Bump ?
> > > > 
> > > > Sorry.  I had actually applied the patch but forgot replying.
> > > 
> > > Hello Shawn,
> > > 
> > > I'd like to apply this patch for 3.14-stable , are you OK with this
> > > please ? Shall I submit it ?
> > 
> > I do not see why this is a stable material.  But you do not need my
> > approval to send patch for stable kernel.  The person you need to
> > convince is Greg.
> 
> Without this patch, you will not get a mac address patched into the DT by the 
> bootloader. Therefore, your device will use a random mac address on the network 
> which is different on every boot. This is not a good thing, don't you agree?

I agree this is not a good thing.  But it's neither a regression nor a
critical issue as defined by stable_kernel_rules.txt.

Shawn

^ 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