* [PATCH 0/4 V3] irqchip: gic: Introduce ARM GICv2m MSI(-X) support
From: Mark Rutland @ 2014-07-18 9:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140717141235.GR13108@titan.lakedaemon.net>
On Thu, Jul 17, 2014 at 03:12:35PM +0100, Jason Cooper wrote:
> On Thu, Jul 17, 2014 at 02:55:34PM +0100, Mark Rutland wrote:
> > Hi Jason,
> >
> > On Thu, Jul 17, 2014 at 02:18:54PM +0100, Jason Cooper wrote:
> > > On Wed, Jul 09, 2014 at 06:05:00PM -0500, suravee.suthikulpanit at amd.com wrote:
> > > > From: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
> > > >
> > > > This patch set introduces support for MSI(-X) in GICv2m specification,
> > > > which is implemented in some variation of GIC400.
> > > >
> > > > This depends on and has been tested with the V7 of"Add support for PCI in AArch64"
> > > > (https://lkml.org/lkml/2014/3/14/320).
> > > >
> > > > Changes in V3:
> > > > * Rebase to git://git.infradead.org/users/jcooper/linux.git irqchip/gic
> > > > (per Jason Cooper request)
> > > > * Misc fix/clean up per Mark Rutland comments
> > > > * Minor Clean up in the driver/irqchip/irq-gic-v2m.c: alloc_msi_irqs()
> > > > * Patch 4 is new to the series:
> > > > * Add ARM64-specific version arch_setup_msi_irqs() to allow support
> > > > for Multiple MSI.
> > > > * Add support for Multiple MSI for GICv2m.
> > > >
> > > > Suravee Suthikulpanit (4):
> > > > irqchip: gic: Add binding probe for ARM GIC400
> > > > irqchip: gic: Restructuring ARM GIC code
> > > > irqchip: gic: Add supports for ARM GICv2m MSI(-X)
> > > > irqchip: gicv2m: Add support for multiple MSI for ARM64 GICv2m
> > >
> > > Ok, patch #1 applied to irqchip/urgent. Patches 2 and 3 applied to
> > > irqchip/gic with irqchip/urgent merged in. To facilitate
> > > testing/merging, I've prepared an unsigned tag for you on the
> > > irqchip/gic branch:
> >
> > I'm a little concerned that this is all going through for v3.17 without
> > a {Reviewed,Acked}-by from Marc or anyone working with GIC{,v2m}.
>
> Well, that's why it's not in irqchip/core yet. ;-) It can be undone if
> needed.
Ah, perhaps I was a litte premature. :)
> > While his comments on v1 have been addressed, he has not had a chance to
> > acknowledge the solutions. I appreciate Marc's holiday is unfortunately
> > timed.
> >
> > I also have an open concern with the binding with regard to the
> > orthogonality of GICV GICH and the MSI registers.
> >
> > Suravee, do you need this urgently for v3.17? I was under the impression
> > that we wouldn't have full PCIe support by then.
>
> If Suravee is ok with it, I can drop them for now and he can resend for
> v3.18. Since we've worked out a way to merge it all in one window, I
> don't think it would hurt anything to wait.
Ok.
> I'll leave these in irqchip/for-next until I hear from Suravee, then
> I'll drop the lot till we hear from Marc and look at the timing.
Keeping it in for-next for testing sounds like a good idea, but until we
hear from Marc I wouldn't want to see this queued for mainline. So the
above sounds fine to me.
Cheers,
Mark.
^ permalink raw reply
* [PATCH 0/4 V3] irqchip: gic: Introduce ARM GICv2m MSI(-X) support
From: Mark Rutland @ 2014-07-18 9:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53C7E23D.1050900@amd.com>
On Thu, Jul 17, 2014 at 03:48:29PM +0100, Suravee Suthikulanit wrote:
> On 7/17/2014 8:55 AM, Mark Rutland wrote:
> > Hi Jason,
> >
> > On Thu, Jul 17, 2014 at 02:18:54PM +0100, Jason Cooper wrote:
> >> On Wed, Jul 09, 2014 at 06:05:00PM -0500, suravee.suthikulpanit at amd.com wrote:
> >>> From: Suravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
> >>>
> >>> This patch set introduces support for MSI(-X) in GICv2m specification,
> >>> which is implemented in some variation of GIC400.
> >>>
> >>> This depends on and has been tested with the V7 of"Add support for PCI in AArch64"
> >>> (https://lkml.org/lkml/2014/3/14/320).
> >>>
> >>> Changes in V3:
> >>> * Rebase to git://git.infradead.org/users/jcooper/linux.git irqchip/gic
> >>> (per Jason Cooper request)
> >>> * Misc fix/clean up per Mark Rutland comments
> >>> * Minor Clean up in the driver/irqchip/irq-gic-v2m.c: alloc_msi_irqs()
> >>> * Patch 4 is new to the series:
> >>> * Add ARM64-specific version arch_setup_msi_irqs() to allow support
> >>> for Multiple MSI.
> >>> * Add support for Multiple MSI for GICv2m.
> >>>
> >>> Suravee Suthikulpanit (4):
> >>> irqchip: gic: Add binding probe for ARM GIC400
> >>> irqchip: gic: Restructuring ARM GIC code
> >>> irqchip: gic: Add supports for ARM GICv2m MSI(-X)
> >>> irqchip: gicv2m: Add support for multiple MSI for ARM64 GICv2m
> >>
> >> Ok, patch #1 applied to irqchip/urgent. Patches 2 and 3 applied to
> >> irqchip/gic with irqchip/urgent merged in. To facilitate
> >> testing/merging, I've prepared an unsigned tag for you on the
> >> irqchip/gic branch:
> >
> > I'm a little concerned that this is all going through for v3.17 without
> > a {Reviewed,Acked}-by from Marc or anyone working with GIC{,v2m}.
>
> > While his comments on v1 have been addressed, he has not had a chance to
> > acknowledge the solutions. I appreciate Marc's holiday is unfortunately
> > timed.
> >
> > I also have an open concern with the binding with regard to the
> > orthogonality of GICV GICH and the MSI registers.
>
> The MSI part is normally enabled from the optional "msi-controller"
> keyword. It should not really matter which compatible ID it uses.
I meant the fact that the MSI registers being described in reg[4],
rather than how the driver determines MSI support.
> Ooops. I noticed that was accidentally dropped the check for
> "msi-controller" in the gicv2m_of_init() function. I'll send a follow
> up patch to fix this.
Sure. Whatever happens we should have both the msi-controller property
and the registers for the MSI block before we enable MSI support.
> > Suravee, do you need this urgently for v3.17? I was under the impression
> > that we wouldn't have full PCIe support by then.
> >
>
> PCI is the dependency for this patch to function. So, it should be
> aligned with upstreaming of PCI patches.
Ok, so it sounds like this can wait for the moment (but we should
definitely ensure this gets some testing before then).
Cheers,
Mark
^ permalink raw reply
* [PATCH 7/8] mailbox: f_mhu: add driver for Fujitsu MHU controller
From: Jassi Brar @ 2014-07-18 9:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53C81B3E.2020503@arm.com>
On 18 July 2014 00:21, Sudeep Holla <sudeep.holla@arm.com> wrote:
> On 17/07/14 18:07, Jassi Brar wrote:
>
>>> I believe that's what we need here if we want this driver to work
>>> on both Juno and your platform. Agree ?
>>>
>> Does this driver not work for Juno?
>
>
> I have not yet tried yet. For sure secure access will explode.
>
OK, I will remove setting up SCFG.
>>>
>>> No what I meant is unless there is a real need to use hard irq, we
>>> should prefer threaded one otherwise.
>>>
>> And how does controller discern a "real need" from a "soft need" to
>> use hard irq?
>> Even if the controller driver pushes data up from a threaded function,
>> the client can't know the context and can't sleep because the
>> intermediate API says the rx_callback should be assumed to be atomic.
>
> Yes I am not arguing on that, it should assume atomic and not sleep.
> I am saying we can avoid rx_callback in interrupt context if possible.
> I will try to look at the protocol implementation tomorrow.
>
There is only one way for controller to push data to client... which
is rx_callback() and it specified to be atomic.
>
>> Again, it maybe more efficient if I see your implementation of the
>> driver and understand your concerns about mine.
>>
>
> As I said its almost same as this, except I call mbox_chan_received_data
> in irq thread context. I prefer enabling other interrupts while copying
> payload data.
>
You call mbox_chan_received_data (which does rx_callback) from
threaded handler. If your client only does atomic stuff in
rx_callback(), then you pay for nothing. If your client does sleepable
stuff then, as you agree, that's wrong.
cheers
-jassi
^ permalink raw reply
* [PATCH v10 01/11] irq: gic: support hip04 gic
From: Mark Rutland @ 2014-07-18 9:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1404957850-13340-2-git-send-email-haojian.zhuang@linaro.org>
On Thu, Jul 10, 2014 at 03:04:00AM +0100, Haojian Zhuang wrote:
> There's a little difference between ARM GIC and HiP04 GIC.
Given that we can't target interrupts correctly without this patch, and
that the GIC in a HiP04 system can't claim compatibility with any other
GIC, I'd call this a major difference.
>
> * HiP04 GIC could support 16 cores at most, and ARM GIC could support
> 8 cores at most. So the difination on GIC_DIST_TARGET registers are
> different since CPU interfaces are increased from 8-bit to 16-bit.
>
> * HiP04 GIC could support 510 interrupts at most, and ARM GIC could
> support 1020 interrupts at most.
>
> Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>
> ---
> Documentation/devicetree/bindings/arm/gic.txt | 1 +
> drivers/irqchip/irq-gic.c | 141 +++++++++++++++++++-------
> 2 files changed, 108 insertions(+), 34 deletions(-)
[...]
> +static bool gic_is_standard(struct gic_chip_data *gic_data)
> +{
> + return (gic_data->nr_cpu_if == 8);
> +}
> +
> +static u32 irqs_per_target_reg(struct gic_chip_data *gic_data)
> +{
> + return (32 / gic_data->nr_cpu_if);
> +}
> +
> +static u32 irq_to_target_reg(struct gic_chip_data *gic_data, u32 irq)
> +{
> + if (!gic_is_standard(gic_data))
> + irq *= 2;
If the function is called gic_is_standard, then the only thing we should
know here is whether the GIC follows the GIC standard, not how it
differs from the standard.
Please rename this function to something like gicd_has_16_bit_targets or
anything else that clearly defines what you're ttrying to derive from
it.
Thanks,
Mark.
^ permalink raw reply
* [PATCH 1/5] arm: dts: omap3-gta04: Add missing nodes to fully describe gta04 board
From: Javier Martinez Canillas @ 2014-07-18 9:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGhQ9VwTXdCHe693PBtaVsv28-heEHY3=qbnn+mdgk3ea3u7qQ@mail.gmail.com>
Hello Marek and Dr. H. Nikolaus,
On Fri, Jul 18, 2014 at 8:55 AM, Joachim Eastwood <manabian@gmail.com> wrote:
> On 16 July 2014 09:17, Dr. H. Nikolaus Schaller <hns@goldelico.com> wrote:
>> Am 15.07.2014 um 14:45 schrieb Joachim Eastwood:
>>
>>> Hi Marek,
>>>
>>> You seem to add some DT nodes for hw that doesn't have drivers in
>>> mainline. I think you should leave those out until the driver itself
>>> is upstream and the bindings for it is documented.
>> is there some policy for only having nodes for existing drivers in DT files?
>
I strongly agree with Joachim on this regard.
>> If I understand the device tree concept correctly, it should not describe drivers
>> (and hence nothing about the state of them being mainlined), but it should statically
>> describe the given hardware in a way that kernel and drivers can read it (or ignore).
>> And even other kernels can use it (because they run on the same hardware).
>>
Yes, it should describe hardware but that description should be
previously agreed and properly documented as was mentioned before.
>> So unless there is an important reason not to have "currently unused" nodes
>> in the DT source/binary (loading time is IMHO neglectable), I would ask that we
>> can keep with the complete DT instead of splitting it up artificially and getting back
>> to the same status (because the hardware does not change over time).
>
I understand your motivation since it will allow you to not have to
maintain a patch-set for your downstream DTS changes but I would like
to ask you the opposite question. What's the benefit for the kernel
community to keep in a mainline DTS a bunch of device nodes with DT
bindings that have not been neither discussed nor documented?
Developers doing a board bring-up usually use the DTS in mainline as a
reference for their boards and having non-documented/agreed DT binding
on the upstream DTS will only bring confusion and frustration to them
IMHO.
We already have some issues with Device Trees (bindings that broke
backward compatibility, drivers implementing custom DT binding instead
of using standard ones, bindings that don't really reflect the actual
H/W, etc), please don't make this even more complicated to developers.
Thanks a lot and best regards,
Javier
^ permalink raw reply
* [GIT PULL] ARM: imx: SoC changes for 3.17
From: Shawn Guo @ 2014-07-18 9:21 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Olof,
To avoid merge conflict, this pull request is based on imx-fixes-3.16-2
I just sent you. Please pull, thanks.
Shawn
The following changes since commit 03e97220b99b8b691ea5b130b7b4c135c9662792:
ARM: clk-imx6q: parent lvds_sel input from upstream clock gates (2014-07-18 15:57:17 +0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-soc-3.17
for you to fetch changes up to 4349c4298f676815bf7ad146cf37e76843054783:
ARM: imx: clk-vf610: fix FlexCAN clock gating (2014-07-18 16:11:40 +0800)
----------------------------------------------------------------
The i.MX SoC changes for 3.17:
- Add devicetree support for i.MX1 and i.MX21 clock driver
- Use CLOCKSOURCE_OF_DECLARE() to initialize timer for DT targets
- Use of_clk_init() to initialize i.MX25 and i.MX27 clock driver in
device tree boot
- Remove i.MX1 camera support
- Remove i.MX27 IP Camera and Lite-Kit board support
- Add suspend and cpuidle support for i.mx6sx
- Clean up unused clk_register_clkdev() lookups
- Update imx-weim bus driver to support populating devices on a simple
bus
- Switch i.MX27 and i.MX6QDL clock driver to use macro for clock IDs
- Make i.MX51 a DT only platform and clean up the non-DT support code
- Support disabling supervisor protect via DT
- Random defconfig updates
----------------------------------------------------------------
Alexander Shiyan (22):
ARM: i.MX: Select HAVE_IMX_SRC for i.MX5 globally
ARM: i.MX1 clk: Add devicetree support
ARM: i.MX: Remove registration helper for i.MX1 USB UDC
ARM: i.MX: Use of_clk_get_by_name() for timer clocks for DT case.
ARM: i.MX: Remove excess variable
ARM: i.MX27 clk: Separate DT and non-DT init procedure
ARM: i.MX27 clk: Use of_clk_init() for DT case
ARM: i.MX clk: Move clock check function in common location
ARM: i.MX system: Simplify handling watchdog clock
ARM: i.MX system: Add a reset fallback if base address of watchdog is not set
ARM: i.MX: Remove Freescale i.MX27 IP Camera board support
ARM: i.MX21 clk: Clock initialization rework
ARM: i.MX21 clk: Remove clk_register_clkdev() for unused clocks
ARM: i.MX21 clk: Cleanup driver
ARM: i.MX21 clk: Add devicetree support
ARM: i.MX: Remove i.MX1 camera support
ARM: i.MX: Remove excess symbols ARCH_MX1, ARCH_MX25 and MACH_MX27
ARM: i.MX: Remove Freescale Logic Product Development i.MX27 Lite-Kit board support
ARM: i.MX27 clk: Introduce DT include for clock provider
ARM: i.MX27 clk: Remove unused definitions
ARM: i.MX27 clk: Add 26 MHz oscillator circuit clock gate
ARM: i.MX: Use CLOCKSOURCE_OF_DECLARE() for DT targets
Anson Huang (4):
ARM: imx: add suspend support for i.mx6sx
ARM: imx: add cpuidle support for i.mx6sx
ARM: imx: mem bit must be cleared before entering DSM mode
ARM: imx: add standby mode support for suspend
Arnd Bergmann (2):
ARM: imx: imx6sx uses imx6q cpuidle code
ARM: imx: build cpu_is_imx6sl function conditionally
Denis Carikli (2):
ARM i.MX25 clk: Fix gpt timer clock.
ARM: i.MX25 clk: Use of_clk_init() for DT case
Fabian Frederick (1):
ARM: imx: use PTR_ERR_OR_ZERO
Fabio Estevam (6):
ARM: imx: defconfig: Select CONFIG_FHANDLE
ARM: imx_v6_v7_defconfig: Select CONFIG_SOC_IMX6SX
ARM: clk-imx51-imx53: Remove clk_register_clkdev()
ARM: imx_v4_v5_defconfig: Add USB device options
ARM: mx6: Only check for 1.2GHz for mx6quad
ARM: imx: clk-imx6sx: register SSI/SSI_IPG as shared gate clocks
Liu Ying (1):
bus: imx-weim: populate devices on a simple bus
Paul Bolle (1):
ARM: imx: remove unused defines
Shawn Guo (24):
Merge tag 'imx-fixes-3.16-2' into imx/soc
ARM: imx: move EHCI platform defines out of platform_data header
ARM: imx5: move SOC_IMX5 and SOC_IMX51 into 'Device tree only'
ARM: imx5: drop option MACH_IMX51_DT
ARM: imx5: remove imx51 non-DT support files
ARM: imx5: remove i.MX5 non-DT device registration helpers
ARM: imx5: make mx51_clocks_init() a DT call
ARM: imx5: drop arguments from mx5_clocks_common_init()
ARM: imx5: tzic_init_irq() can directly be .init_irq hook
ARM: imx5: remove function imx51_soc_init()
ARM: imx5: call mxc_timer_init_dt() on imx51
ARM: imx5: retrieve iim base from device tree
ARM: imx5: remove header crm-regs-imx5.h
ARM: imx5: use dynamic mapping for CCM block
ARM: imx5: use dynamic mapping for DPLL block
ARM: imx5: reuse clock CCM mapping in pm code
ARM: imx5: use dynamic mapping for Cortex and GPC block
ARM: imx5: move init hooks into mach-imx5x.c
ARM: imx5: remove file mm-imx5.c
ARM: imx5: clean function declarations in mx51.h
ARM: imx5: remove mx51.h and mx53.h
ARM: imx6qdl: switch to use macro for clock ID
ARM: imx: mark .dt_compat as const
ARM: imx: drop PL310 errata 588369 and 727915
Silvio Fricke (2):
ARM: imx_v6_v7_defconfig: Enable STMPE gpio support
ARM: imx_v6_v7_defconfig: Enable flexcan driver for can support
Stefan Agner (2):
ARM: imx_v6_v7_defconfig: add FSL_EDMA and PRINTK_TIME
ARM: imx: clk-vf610: fix FlexCAN clock gating
Steffen Trumtrar (2):
ARM: i.MX: allow disabling supervisor protect via DT
ARM: i.MX53: globally disable supervisor protect
.../devicetree/bindings/clock/imx1-clock.txt | 26 +
.../devicetree/bindings/clock/imx21-clock.txt | 28 +
.../devicetree/bindings/clock/imx27-clock.txt | 127 +---
.../devicetree/bindings/clock/imx6q-clock.txt | 220 +-----
arch/arm/configs/imx_v4_v5_defconfig | 5 +-
arch/arm/configs/imx_v6_v7_defconfig | 9 +-
arch/arm/configs/multi_v7_defconfig | 2 +-
arch/arm/configs/mxs_defconfig | 1 +
arch/arm/mach-imx/Kconfig | 59 +-
arch/arm/mach-imx/Makefile | 11 +-
arch/arm/mach-imx/clk-imx1.c | 151 ++--
arch/arm/mach-imx/clk-imx21.c | 299 ++++----
arch/arm/mach-imx/clk-imx25.c | 47 +-
arch/arm/mach-imx/clk-imx27.c | 452 +++++------
arch/arm/mach-imx/clk-imx31.c | 6 +-
arch/arm/mach-imx/clk-imx35.c | 6 +-
arch/arm/mach-imx/clk-imx51-imx53.c | 256 +++----
arch/arm/mach-imx/clk-imx6q.c | 540 +++++++-------
arch/arm/mach-imx/clk-imx6sl.c | 11 +-
arch/arm/mach-imx/clk-imx6sx.c | 25 +-
arch/arm/mach-imx/clk-vf610.c | 8 +-
arch/arm/mach-imx/clk.c | 10 +
arch/arm/mach-imx/clk.h | 9 +
arch/arm/mach-imx/common.h | 32 +-
arch/arm/mach-imx/cpu-imx5.c | 25 +-
arch/arm/mach-imx/cpu.c | 13 +
arch/arm/mach-imx/cpuidle-imx6q.c | 6 +-
arch/arm/mach-imx/crm-regs-imx5.h | 600 ---------------
arch/arm/mach-imx/devices-imx51.h | 66 --
arch/arm/mach-imx/devices/Kconfig | 9 +-
arch/arm/mach-imx/devices/Makefile | 2 -
arch/arm/mach-imx/devices/devices-common.h | 26 -
arch/arm/mach-imx/devices/platform-fec.c | 12 -
arch/arm/mach-imx/devices/platform-fsl-usb2-udc.c | 5 -
arch/arm/mach-imx/devices/platform-imx-i2c.c | 26 -
arch/arm/mach-imx/devices/platform-imx-keypad.c | 10 -
arch/arm/mach-imx/devices/platform-imx-ssi.c | 20 -
arch/arm/mach-imx/devices/platform-imx-uart.c | 22 -
arch/arm/mach-imx/devices/platform-imx2-wdt.c | 18 -
arch/arm/mach-imx/devices/platform-imx_udc.c | 75 --
arch/arm/mach-imx/devices/platform-mx1-camera.c | 42 --
arch/arm/mach-imx/devices/platform-mxc-ehci.c | 9 -
arch/arm/mach-imx/devices/platform-mxc_nand.c | 5 -
arch/arm/mach-imx/devices/platform-mxc_rnga.c | 5 +-
arch/arm/mach-imx/devices/platform-pata_imx.c | 10 -
.../mach-imx/devices/platform-sdhci-esdhc-imx.c | 24 -
arch/arm/mach-imx/devices/platform-spi_imx.c | 27 -
arch/arm/mach-imx/ehci-imx25.c | 1 +
arch/arm/mach-imx/ehci-imx27.c | 1 +
arch/arm/mach-imx/ehci-imx31.c | 1 +
arch/arm/mach-imx/ehci-imx35.c | 1 +
arch/arm/mach-imx/ehci-imx5.c | 171 -----
arch/arm/mach-imx/ehci.h | 43 ++
arch/arm/mach-imx/gpc.c | 5 +-
arch/arm/mach-imx/hardware.h | 2 -
arch/arm/mach-imx/imx25-dt.c | 6 -
arch/arm/mach-imx/imx27-dt.c | 6 -
arch/arm/mach-imx/imx31-dt.c | 2 +-
arch/arm/mach-imx/imx35-dt.c | 2 +-
arch/arm/mach-imx/iomux-mx51.h | 827 ---------------------
arch/arm/mach-imx/mach-armadillo5x0.c | 1 +
arch/arm/mach-imx/mach-cpuimx27.c | 1 +
arch/arm/mach-imx/mach-cpuimx35.c | 1 +
arch/arm/mach-imx/mach-eukrea_cpuimx25.c | 1 +
arch/arm/mach-imx/mach-imx27_visstrim_m10.c | 1 +
arch/arm/mach-imx/mach-imx27ipcam.c | 77 --
arch/arm/mach-imx/mach-imx27lite.c | 83 ---
arch/arm/mach-imx/mach-imx50.c | 5 +-
arch/arm/mach-imx/{imx51-dt.c => mach-imx51.c} | 45 +-
arch/arm/mach-imx/mach-imx53.c | 19 +-
arch/arm/mach-imx/mach-imx6q.c | 4 +-
arch/arm/mach-imx/mach-imx6sl.c | 2 +-
arch/arm/mach-imx/mach-imx6sx.c | 10 +-
arch/arm/mach-imx/mach-mx25_3ds.c | 1 +
arch/arm/mach-imx/mach-mx27_3ds.c | 1 +
arch/arm/mach-imx/mach-mx31_3ds.c | 1 +
arch/arm/mach-imx/mach-mx31lilly.c | 1 +
arch/arm/mach-imx/mach-mx31lite.c | 1 +
arch/arm/mach-imx/mach-mx31moboard.c | 5 +-
arch/arm/mach-imx/mach-mx35_3ds.c | 1 +
arch/arm/mach-imx/mach-pca100.c | 1 +
arch/arm/mach-imx/mach-pcm037.c | 1 +
arch/arm/mach-imx/mach-pcm038.c | 1 +
arch/arm/mach-imx/mach-pcm043.c | 1 +
arch/arm/mach-imx/mach-vf610.c | 2 +-
arch/arm/mach-imx/mach-vpr200.c | 1 +
arch/arm/mach-imx/mm-imx5.c | 155 ----
arch/arm/mach-imx/mx1-camera-fiq-ksym.c | 18 -
arch/arm/mach-imx/mx1-camera-fiq.S | 35 -
arch/arm/mach-imx/mx31moboard-devboard.c | 5 +-
arch/arm/mach-imx/mx31moboard-marxbot.c | 5 +-
arch/arm/mach-imx/mx31moboard-smartbot.c | 5 +-
arch/arm/mach-imx/mx51.h | 346 ---------
arch/arm/mach-imx/mx53.h | 342 ---------
arch/arm/mach-imx/mxc.h | 7 +
arch/arm/mach-imx/pm-imx5.c | 98 ++-
arch/arm/mach-imx/pm-imx6.c | 67 +-
arch/arm/mach-imx/system.c | 24 +-
arch/arm/mach-imx/time.c | 55 +-
arch/arm/mach-imx/tzic.c | 9 +-
drivers/bus/imx-weim.c | 4 +-
include/dt-bindings/clock/imx1-clock.h | 40 +
include/dt-bindings/clock/imx21-clock.h | 80 ++
include/dt-bindings/clock/imx27-clock.h | 108 +++
include/dt-bindings/clock/imx6qdl-clock.h | 224 ++++++
include/dt-bindings/clock/vf610-clock.h | 4 +-
include/linux/platform_data/camera-mx1.h | 35 -
include/linux/platform_data/usb-ehci-mxc.h | 46 --
include/linux/platform_data/usb-imx_udc.h | 23 -
109 files changed, 1805 insertions(+), 4663 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/imx1-clock.txt
create mode 100644 Documentation/devicetree/bindings/clock/imx21-clock.txt
delete mode 100644 arch/arm/mach-imx/crm-regs-imx5.h
delete mode 100644 arch/arm/mach-imx/devices-imx51.h
delete mode 100644 arch/arm/mach-imx/devices/platform-imx_udc.c
delete mode 100644 arch/arm/mach-imx/devices/platform-mx1-camera.c
delete mode 100644 arch/arm/mach-imx/ehci-imx5.c
create mode 100644 arch/arm/mach-imx/ehci.h
delete mode 100644 arch/arm/mach-imx/iomux-mx51.h
delete mode 100644 arch/arm/mach-imx/mach-imx27ipcam.c
delete mode 100644 arch/arm/mach-imx/mach-imx27lite.c
rename arch/arm/mach-imx/{imx51-dt.c => mach-imx51.c} (51%)
delete mode 100644 arch/arm/mach-imx/mm-imx5.c
delete mode 100644 arch/arm/mach-imx/mx1-camera-fiq-ksym.c
delete mode 100644 arch/arm/mach-imx/mx1-camera-fiq.S
delete mode 100644 arch/arm/mach-imx/mx51.h
delete mode 100644 arch/arm/mach-imx/mx53.h
create mode 100644 include/dt-bindings/clock/imx1-clock.h
create mode 100644 include/dt-bindings/clock/imx21-clock.h
create mode 100644 include/dt-bindings/clock/imx27-clock.h
create mode 100644 include/dt-bindings/clock/imx6qdl-clock.h
delete mode 100644 include/linux/platform_data/camera-mx1.h
delete mode 100644 include/linux/platform_data/usb-imx_udc.h
^ permalink raw reply
* The imx6q suspend/resume is broken on 3.16-rc due to PCIe
From: Lucas Stach @ 2014-07-18 9:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <247043c4c45c41bf9eaa09aaf91bcc46@DM2PR0301MB0862.namprd03.prod.outlook.com>
Am Freitag, den 18.07.2014, 02:11 +0000 schrieb
Hong-Xing.Zhu at freescale.com:
> > -----Original Message-----
> > From: Lucas Stach [mailto:l.stach at pengutronix.de]
> > Sent: Thursday, July 17, 2014 9:55 PM
> > To: Guo Shawn-R65073
> > Cc: Zhu Richard-R65037; linux-pci at vger.kernel.org; Sascha Hauer; Bjorn Helgaas;
> > Shawn Guo; Fabio Estevam; linux-arm-kernel at lists.infradead.org
> > Subject: Re: The imx6q suspend/resume is broken on 3.16-rc due to PCIe
> >
> > Hi Shawn,
> >
> > Am Mittwoch, den 16.07.2014, 14:55 +0800 schrieb Shawn Guo:
> > > On Mon, Jul 07, 2014 at 09:55:03PM +0800, Shawn Guo wrote:
> > > > On Mon, Jul 07, 2014 at 11:10:51AM +0200, Lucas Stach wrote:
> > > > > Hi Shawn,
> > > > >
> > > > > Over the weekend I tried to reproduce your problem on a SabreSD
> > > > > board, but wasn't able to trigger the issue. 3.16-rc3 with PCIe
> > > > > active works just fine over a suspend and resume cycle for me.
> > > >
> > > > That's strange. In my setup, PCIe support is enabled in kernel and
> > > > DT, but I do not have a PCIe device connected to the board.
> > > >
> > > > >
> > > > > One possibly relevant difference is that I've booted with NFSroot,
> > > > > while it seems you are using a SATA connected device. Is this right?
> > > >
> > > > I have a SATA disk connected, but did boot with NFSroot.
> > > >
> > > > > If so,
> > > > > can you test if it works if you boot from SDcard or the like? This
> > > > > might be relevant as PCIe and SATA share some clocks.
> > > >
> > > > I tried to disable SATA support completely, but it doesn't help.
> > >
> > > Lucas, any news on this? Or should we just try to use Richard's patch
> > > to solve the problem?
> >
> > I would like to understand the problem first before throwing "fixes" at the
> > issue. As you said this isn't a regression we are in no hurry and should try
> > to analyze the issue properly. I just retested and I'm still not able to
> > reproduce the issue on my SabreSD. Maybe there are board revision that exhibit
> > different behavior? My board has two sticks on saying "Rev B3" and "Rev X3".
> >
> > As you can see from the log suspend/resume is working fine for me with kernel
> > 3.16-rc5 + imx_v6_v7_defconfig.
> [Richard] As I know that imx6 pcie is not enabled in imx_v6_v7_defconfig in default.
> Menu-config is required if you want to tests system suspend/resume with pcie built-in.
> Just double confirm, is the pcie built-in at your side?
This is not right, PCI is enabled in imx_v6_v7_defconfig since
c0bea59ca58e30fb8fd29254569bdaae482398ad "ARM: imx_v6_v7_defconfig:
Select PCI support".
However I seem to have a board with rev 1.1 silicon and although the pci
driver starts up it never establishes a link. So my board may just work
by chance as I don't really know the differences between rev 1.1 silicon
and later revisions.
Regards,
Lucas
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [PATCH v2 1/3] ACPI: ARM64 does not have a BIOS add config for BIOS table scan.
From: Hanjun Guo @ 2014-07-18 9:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <3908561D78D1C84285E8C5FCA982C28F32866139@ORSMSX113.amr.corp.intel.com>
On 2014-7-18 0:58, Luck, Tony wrote:
>> Tony, if it is ok with you, I will modify the patch and will not select
>> ACPI_LEGACY_TABLES_LOOKUP on IA64, I'm waiting for your final confirmation.
>
> Confirmed. Thanks Peter for catching this.
Great, I will update the patch and send out soon.
Thanks
Hanjun
^ permalink raw reply
* [PATCH 5/5] ARM: sunxi: Add A31 RTC driver to sunxi_defconfig
From: Chen-Yu Tsai @ 2014-07-18 9:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140718081222.GK20328@lukather>
On Fri, Jul 18, 2014 at 4:12 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> On Mon, Jul 14, 2014 at 03:32:17PM +0800, Chen-Yu Tsai wrote:
>> Now that we have a driver for A31's RTC, enable it
>> in the default sunxi config.
>
> It would be great if you could do this for multi_v7 as well.
No problem. I'll add it in the next version.
ChenYu
^ permalink raw reply
* [RFC] PCI: pci-imx6: Add delay to workaround kernel hang
From: Lucas Stach @ 2014-07-18 9:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAJ+vNU0DNCT5pcvnptNBo-tPTVOH1HnrCwy7uCZt33dfyq8U-g@mail.gmail.com>
Hi Tim,
Am Donnerstag, den 26.06.2014, 17:29 -0700 schrieb Tim Harvey:
[...]
> Shawn / Richard,
>
> I am also affected by this issue on IMX6 boards that I support. If I
> enable PCI in the bootloader I see similar hangs.
>
> I have the following hardware configurations on my bench:
> 1. IMX6DL + i210 (same PCI setup as Fabio's above, but DL instead of Q)
> 2. IMX6Q + ath9k device
> 3. IMX6DL + PLX PEX860x PCIe-to-PCIe bridge with various devices
> behind the bridge, using a clock buffer from IMX6 PCIe clock
> 4. IMX6Q + PLX PEX860x PCIe-to-PCIe bridge with various devices
> behind the bridge, using a clock buffer from IMX6 PCIe clock
> 5. IMX6Q + PLX PEX860x PCIe-to-PCIe bridge with various devices
> behind the bridge using a clock generator (always on, ignoring the
> PCIe clock)
>
> For all of the above I have no PCI issues using
> 3.14/3.15/3.16-rc2/vendor 3.10.17_1.0.0_ga unless I enable PCI in the
> bootloader. When I do so, all of the above configurations hang
> somewhere around PCI init/enumeration. The same occurs with the most
> recent vendor kernel 3.10.17_1.0.0_ga kernel (works when PCI is
> disabled in the bootloader, hangs otherwise).
>
> When I apply Fabio's patch above to the 3.16-rc2 kernel I find that
> scenarios #4 and #5 above then work, #3 boots but the PLX bridge fails
> all config cycles (0xff's), #2 boots but with no PCIe link, and #1
> above still hangs. Previously, when I have dug into this particular
> 'hang' issue on 3.15 I found that the delay needed to be between
> imx6_pcie_probe() requesting and asserting reset_gpio low, and before
> setting IOMUX_GPR1:18 to power down the PCIe PHY (note here, that the
> PHY is currently enabled in the bootloader when PCI is enabled there).
>
> When I apply Fabio's patch above to the most recent vendor kernel
> 3.10.17_1.0.0_ga I still hang in all cases.
>
> So while I agree there is something horribly wrong with IMX6 PCI
> still, I don't think Fabio's patch is the right solution and I don't
> have anything better at this point in time. I'm happy to share any
> hardware with anyone that can work through this issue.
>
Can you try if the attached patch makes any difference?
Regards,
Lucas
------------------------------>8---------------------------------
>From 0e2fc443c760290166f6371d50813e6c30a678da Mon Sep 17 00:00:00 2001
From: Lucas Stach <l.stach@pengutronix.de>
Date: Thu, 17 Jul 2014 18:54:44 +0200
Subject: [PATCH] try forcing LTSSM into detect state
---
drivers/pci/host/pci-imx6.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/pci/host/pci-imx6.c b/drivers/pci/host/pci-imx6.c
index a568efaa331c..afa450c54aba 100644
--- a/drivers/pci/host/pci-imx6.c
+++ b/drivers/pci/host/pci-imx6.c
@@ -215,6 +215,8 @@ static int imx6_pcie_assert_core_reset(struct pcie_port *pp)
{
struct imx6_pcie *imx6_pcie = to_imx6_pcie(pp);
+ 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
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply related
* [GIT PULL] ARM: imx: device tree updates for 3.17
From: Shawn Guo @ 2014-07-18 9:27 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Olof,
For sake of dependency, this pull request is based on imx-soc-3.17
I just sent. Please pull and take care of the dependency, thanks.
Shawn
The following changes since commit 4349c4298f676815bf7ad146cf37e76843054783:
ARM: imx: clk-vf610: fix FlexCAN clock gating (2014-07-18 16:11:40 +0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux.git tags/imx-dt-3.17
for you to fetch changes up to 69603fbbc4798e8d02cb822edf5dce3f8a625427:
ARM: dts: vf610: add FlexCAN node (2014-07-18 16:49:47 +0800)
----------------------------------------------------------------
The i.MX device tree updates for 3.17:
- Add device tree sources and pin function header for i.MX6SX SoC
- Initial imx6sx-sdb board support with FEC, MMC, USB, PMIC, Audio
and GPIO key enabled
- New board support: mbimxsd25 and mbimxsd27 from Eukrea, aristainetos
imx6dl boards, Rex Pro and Basic, Ka-Ro TX6
- Restructure imx6qdl-wandboard.dtsi for new rev C1 board
- Split M28EVK and M53EVK into SoM and EVK parts
- A few correction around SDMA, SSI and SATA device nodes
- Add eSATA support for Cubox-i board
- Updates on edmqmx6 to enable PCIe, I2C and CAN
- Use DT macro for clock ID for imx27 and imx6qdl
- Add FlexCAN support for VF610 SoC
----------------------------------------------------------------
Alexander Shiyan (3):
ARM: dts: Add support for the cpuimx27 board from Eukrea and its baseboard
ARM: dts: i.MX35: Add GPT node
ARM: i.MX27 clk: dts: Use clock defines in DTS files
Alexandre Belloni (1):
ARM: dt: imx28-cfa10036: introduce a regulator for mmc0
Anson Huang (2):
ARM: dts: imx6sx-sdb: add gpio key support
ARM: dts: imx6sx: iomux-gpr syscon is compatible to imx6q
Anssi Hannula (2):
ARM: dts: imx6: remove wrong spdif rxtx2 clock
ARM: dts: imx6: remove non-working spdif rxtx4 and rxtx6 clocks
Denis Carikli (3):
ARM: dts: imx25: mbimxsd25: Add displays support.
ARM: dts: mbimxsd25: cmo-qvga: Fix lcd regulator
ARM: dts: i.MX25: Fix gpt timers clocks.
Fabio Estevam (13):
ARM: dts: imx6qdl-sabresd: Configure the ECSPI1 chip select pin
ARM: dts: imx51-babbage: Add PMIC RTC support
ARM: dts: imx6q-udoo: Add USB Host support
ARM: dts: imx6sx: Use "vddarm" as the regulator name
ARM: dts: imx6sx: Fix usbmisc compatible string
ARM: dts: imx6sx-sdb: Add USB support
ARM: dts: imx6sx-sdb: Add PMIC support
ARM: dts: mx6: Disable the keypad in the dtsi files
ARM: dts: imx25-pdk: Add USB OTG support
ARM: dts: imx6sx: Fix sdma node
ARM: dts: imx6sx: Pass the fsl,fifo-depth property
ARM: dts: imx6sx-sdb: Add audio support
ARM: imx6: Align ssi nodes between mx6 variants
Fugang Duan (1):
ARM: dts: imx6sl: add fec sleep pinctrl for pin PM state
George Joseph (1):
ARM: dts: Restructure imx6qdl-wandboard.dtsi for new rev C1 board.
Heiko Schocher (1):
ARM: dts: imx6: add aristainetos board support
Iain Paton (1):
ARM: dts: imx6: RIoTboard explicitly define pad settings
Lothar Wa?mann (2):
ARM: dts: imx6: add missing compatible and clock properties for kpp
ARM: dts: imx6: add support for Ka-Ro TX6 modules
Marek Vasut (2):
ARM: dts: mxs: Split M28EVK into SoM and EVK parts
ARM: dts: mx5: Split M53EVK into SoM and EVK parts
Markus Pargmann (4):
ARM: dts: imx50: add ssi dma properties
ARM: dts: imx5: remove fsl,ssi-dma-events
ARM: dts: imx6qdl: remove fsl,ssi-dma-events
ARM: dts: imx: remove ssi fsl,mode for audio cards
Philipp Zabel (2):
ARM: dts: pfla02: Add ethernet phy supply regulator
ARM: dts: imx6qdl: Add CSI device tree port nodes for IPU1 and IPU2
Robert Nelson (2):
ARM: dts: add initial Rex Pro board support
ARM: dts: add initial Rex Basic board support
Russell King (2):
ARM: dts: cubox-i: add eSATA DT configuration
ARM: dts: cubox-i: disable spread-spectrum for Cubox-i eSATA
Shawn Guo (7):
Merge tag 'imx-soc-3.17' into imx/dt
ARM: dts: imx: add pin function header for imx6sx
ARM: dts: imx: add initial imx6sx device tree source
ARM: dts: imx: add initial imx6sx-sdb board support
ARM: dts: imx6qdl: use DT macro for clock ID
ARM: dts: imx: correct sdma compatbile for imx6sl and imx6sx
ARM: dts: imx53: correct clock-names of SATA node
Silvio Fricke (3):
ARM: dts: imx6: edmqmx6: Add PCIe support
ARM: dts: imx6: edmqmx6: Add two other i2c buses
ARM: dts: imx6: edmqmx6: Add can bus
Stefan Agner (2):
ARM: dts: vf610: fix length of eshdc1 register property
ARM: dts: vf610: add FlexCAN node
Steffen Trumtrar (1):
ARM: dts: i.MX53: add aipstz nodes
Tim Harvey (2):
ARM: dts: imx6: ventana: change sound device name
ARM: dts: imx6: ventana: update model to reflect Dual/Solo CPU types
arch/arm/boot/dts/Makefile | 19 +
.../imx25-eukrea-mbimxsd25-baseboard-cmo-qvga.dts | 73 +
.../imx25-eukrea-mbimxsd25-baseboard-dvi-svga.dts | 45 +
.../imx25-eukrea-mbimxsd25-baseboard-dvi-vga.dts | 45 +
.../boot/dts/imx25-eukrea-mbimxsd25-baseboard.dts | 1 -
arch/arm/boot/dts/imx25-pdk.dts | 8 +-
arch/arm/boot/dts/imx25.dtsi | 8 +-
arch/arm/boot/dts/imx27-eukrea-cpuimx27.dtsi | 296 ++++
.../boot/dts/imx27-eukrea-mbimxsd27-baseboard.dts | 273 ++++
arch/arm/boot/dts/imx27-pdk.dts | 2 +-
arch/arm/boot/dts/imx27-phytec-phycore-rdk.dts | 2 +-
arch/arm/boot/dts/imx27-phytec-phycore-som.dtsi | 3 +-
arch/arm/boot/dts/imx27.dtsi | 115 +-
arch/arm/boot/dts/imx28-cfa10036.dts | 22 +
arch/arm/boot/dts/imx28-m28.dtsi | 87 ++
arch/arm/boot/dts/imx28-m28evk.dts | 62 +-
.../boot/dts/imx35-eukrea-mbimxsd35-baseboard.dts | 1 -
arch/arm/boot/dts/imx35.dtsi | 8 +
arch/arm/boot/dts/imx50.dtsi | 8 +-
arch/arm/boot/dts/imx51-babbage.dts | 2 +-
.../boot/dts/imx51-eukrea-mbimxsd51-baseboard.dts | 1 -
arch/arm/boot/dts/imx51.dtsi | 3 -
arch/arm/boot/dts/imx53-m53.dtsi | 140 ++
arch/arm/boot/dts/imx53-m53evk.dts | 113 +-
arch/arm/boot/dts/imx53-mba53.dts | 1 -
arch/arm/boot/dts/imx53-qsb-common.dtsi | 1 -
arch/arm/boot/dts/imx53-tx53.dtsi | 1 -
arch/arm/boot/dts/imx53-voipac-bsb.dts | 1 -
arch/arm/boot/dts/imx53.dtsi | 15 +-
arch/arm/boot/dts/imx6dl-aristainetos_4.dts | 85 ++
arch/arm/boot/dts/imx6dl-aristainetos_7.dts | 74 +
arch/arm/boot/dts/imx6dl-gw51xx.dts | 2 +-
arch/arm/boot/dts/imx6dl-gw52xx.dts | 2 +-
arch/arm/boot/dts/imx6dl-gw53xx.dts | 2 +-
arch/arm/boot/dts/imx6dl-gw54xx.dts | 2 +-
arch/arm/boot/dts/imx6dl-rex-basic.dts | 30 +
arch/arm/boot/dts/imx6dl-riotboard.dts | 33 +-
arch/arm/boot/dts/imx6dl-tx6dl-comtft.dts | 103 ++
arch/arm/boot/dts/imx6dl-tx6u-801x.dts | 177 +++
arch/arm/boot/dts/imx6dl-tx6u-811x.dts | 150 ++
arch/arm/boot/dts/imx6dl-wandboard-revb1.dts | 22 +
arch/arm/boot/dts/imx6dl-wandboard.dts | 2 +-
arch/arm/boot/dts/imx6dl.dtsi | 17 +-
arch/arm/boot/dts/imx6q-cubox-i.dts | 4 +
arch/arm/boot/dts/imx6q-dmo-edmqmx6.dts | 54 +
arch/arm/boot/dts/imx6q-gw51xx.dts | 2 +-
arch/arm/boot/dts/imx6q-gw52xx.dts | 2 +-
arch/arm/boot/dts/imx6q-gw53xx.dts | 2 +-
arch/arm/boot/dts/imx6q-gw5400-a.dts | 5 +-
arch/arm/boot/dts/imx6q-gw54xx.dts | 2 +-
arch/arm/boot/dts/imx6q-rex-pro.dts | 34 +
arch/arm/boot/dts/imx6q-tx6q-1010-comtft.dts | 103 ++
arch/arm/boot/dts/imx6q-tx6q-1010.dts | 177 +++
arch/arm/boot/dts/imx6q-tx6q-1020-comtft.dts | 136 ++
arch/arm/boot/dts/imx6q-tx6q-1020.dts | 210 +++
arch/arm/boot/dts/imx6q-tx6q-1110.dts | 154 ++
arch/arm/boot/dts/imx6q-udoo.dts | 32 +
arch/arm/boot/dts/imx6q-wandboard-revb1.dts | 26 +
arch/arm/boot/dts/imx6q-wandboard.dts | 2 +-
arch/arm/boot/dts/imx6q.dtsi | 35 +-
arch/arm/boot/dts/imx6qdl-aristainetos.dtsi | 418 ++++++
arch/arm/boot/dts/imx6qdl-gw52xx.dtsi | 5 +-
arch/arm/boot/dts/imx6qdl-gw53xx.dtsi | 5 +-
arch/arm/boot/dts/imx6qdl-gw54xx.dtsi | 6 +-
arch/arm/boot/dts/imx6qdl-nitrogen6x.dtsi | 1 -
arch/arm/boot/dts/imx6qdl-phytec-pfla02.dtsi | 1 +
arch/arm/boot/dts/imx6qdl-rex.dtsi | 357 +++++
arch/arm/boot/dts/imx6qdl-sabrelite.dtsi | 1 -
arch/arm/boot/dts/imx6qdl-sabresd.dtsi | 2 +-
arch/arm/boot/dts/imx6qdl-tx6.dtsi | 696 +++++++++
arch/arm/boot/dts/imx6qdl-wandboard-revb1.dtsi | 42 +
arch/arm/boot/dts/imx6qdl-wandboard-revc1.dtsi | 41 +
arch/arm/boot/dts/imx6qdl-wandboard.dtsi | 22 -
arch/arm/boot/dts/imx6qdl.dtsi | 161 +-
arch/arm/boot/dts/imx6sl-evk.dts | 17 +-
arch/arm/boot/dts/imx6sl.dtsi | 12 +-
arch/arm/boot/dts/imx6sx-pinfunc.h | 1544 ++++++++++++++++++++
arch/arm/boot/dts/imx6sx-sdb.dts | 479 ++++++
arch/arm/boot/dts/imx6sx.dtsi | 1208 +++++++++++++++
arch/arm/boot/dts/vf610.dtsi | 25 +-
80 files changed, 7692 insertions(+), 388 deletions(-)
create mode 100644 arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-cmo-qvga.dts
create mode 100644 arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-dvi-svga.dts
create mode 100644 arch/arm/boot/dts/imx25-eukrea-mbimxsd25-baseboard-dvi-vga.dts
create mode 100644 arch/arm/boot/dts/imx27-eukrea-cpuimx27.dtsi
create mode 100644 arch/arm/boot/dts/imx27-eukrea-mbimxsd27-baseboard.dts
create mode 100644 arch/arm/boot/dts/imx28-m28.dtsi
create mode 100644 arch/arm/boot/dts/imx53-m53.dtsi
create mode 100644 arch/arm/boot/dts/imx6dl-aristainetos_4.dts
create mode 100644 arch/arm/boot/dts/imx6dl-aristainetos_7.dts
create mode 100644 arch/arm/boot/dts/imx6dl-rex-basic.dts
create mode 100644 arch/arm/boot/dts/imx6dl-tx6dl-comtft.dts
create mode 100644 arch/arm/boot/dts/imx6dl-tx6u-801x.dts
create mode 100644 arch/arm/boot/dts/imx6dl-tx6u-811x.dts
create mode 100644 arch/arm/boot/dts/imx6dl-wandboard-revb1.dts
create mode 100644 arch/arm/boot/dts/imx6q-rex-pro.dts
create mode 100644 arch/arm/boot/dts/imx6q-tx6q-1010-comtft.dts
create mode 100644 arch/arm/boot/dts/imx6q-tx6q-1010.dts
create mode 100644 arch/arm/boot/dts/imx6q-tx6q-1020-comtft.dts
create mode 100644 arch/arm/boot/dts/imx6q-tx6q-1020.dts
create mode 100644 arch/arm/boot/dts/imx6q-tx6q-1110.dts
create mode 100644 arch/arm/boot/dts/imx6q-wandboard-revb1.dts
create mode 100644 arch/arm/boot/dts/imx6qdl-aristainetos.dtsi
create mode 100644 arch/arm/boot/dts/imx6qdl-rex.dtsi
create mode 100644 arch/arm/boot/dts/imx6qdl-tx6.dtsi
create mode 100644 arch/arm/boot/dts/imx6qdl-wandboard-revb1.dtsi
create mode 100644 arch/arm/boot/dts/imx6qdl-wandboard-revc1.dtsi
create mode 100644 arch/arm/boot/dts/imx6sx-pinfunc.h
create mode 100644 arch/arm/boot/dts/imx6sx-sdb.dts
create mode 100644 arch/arm/boot/dts/imx6sx.dtsi
^ permalink raw reply
* [PATCHv4 5/5] arm64: cpuinfo: print info for all CPUs
From: Catalin Marinas @ 2014-07-18 9:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140717172858.GD4844@arm.com>
On Thu, Jul 17, 2014 at 06:28:58PM +0100, Will Deacon wrote:
> On Thu, Jul 17, 2014 at 06:10:58PM +0100, Catalin Marinas wrote:
> > On Thu, Jul 17, 2014 at 02:55:37PM +0100, Peter Maydell wrote:
> > > On 17 July 2014 13:35, Will Deacon <will.deacon@arm.com> wrote:
> > > > We're not denying the possibility of heterogeneity, we're trying to expose a
> > > > consistent view of the system to userspace. Differences between cores should
> > > > be dealt with by the kernel (e.g. IKS, HMP scheduling), not blindly
> > > > passed off to userspace.
> > >
> > > On that basis, why report anything at all about invididual cores?
> > > Just have /proc/cpuinfo report "number of processors: 4" and
> > > no per-CPU information at all...
> >
> > We lost a lot of time on this already (given the internal threads). So
> > my proposal is to go ahead with Mark's patch with per-CPU features. They
> > currently just include the same elf_hwcap multiple times. If we ever
> > need to present different features, the conditions would be:
> >
> > 1. Never report more than elf_hwcap
> > 2. elf_hwcap can only include non-symmetric features *if* Linux gets a
> > way to transparently handle migration or emulation
>
> ... making the point of a per-cpu field entirely pointless ;)
Well, if we can support such features in a transparent way,
/proc/cpuinfo becomes more informative (e.g. user wondering why a
process runs only on certain CPUs).
But to be clear (and I think we are aligned), I don't trust user space
to parse all processors in /proc/cpuinfo and make an informed selection
of CPU affinity to avoid SIGILL.
Yet another option would be to have a single features/hwcap line and
present the extra features in a human (and only human) readable form
(e.g. some haiku that changes with every kernel release ;)).
--
Catalin
^ permalink raw reply
* [PATCH 0/9] usb: musb: several bugfixes for the musb driver
From: Lothar Waßmann @ 2014-07-18 9:31 UTC (permalink / raw)
To: linux-arm-kernel
The first three patches do some source code cleanup in the files that
are modified in the subsequent patches.
Patch 4 carries the proper fix reported in commit:
7adb5c876e9c ("usb: musb: Fix panic upon musb_am335x module removal")
Patch 6 makes the USBOTG_ID pin override via the USB_MODE register
really work.
Patch 5 makes the error message upon driver probe failure visible
without having to recompile the driver with DEBUG enabled.
Patch 7 makes sure the parameters for the usb_gen_phy are properly set
up before registering it.
Patch 8 makes it possible to use the driver with HW that requires
external regulators or clocks.
Patch 9 reinstates module unloading support for the musb_am335x driver
which was disabled due to a false failure analysis
^ permalink raw reply
* [PATCH 1/9] usb: musb: core: cleanup - remove some useless 'break's from switch statements
From: Lothar Waßmann @ 2014-07-18 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405675890-8802-1-git-send-email-LW@KARO-electronics.de>
Signed-off-by: Lothar Wa?mann <LW@KARO-electronics.de>
---
drivers/usb/musb/musb_core.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index b841ee0..8623112 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -680,7 +680,6 @@ static irqreturn_t musb_stage0_irq(struct musb *musb, u8 int_usb,
default:
/* "should not happen" */
musb->is_active = 0;
- break;
}
}
@@ -737,7 +736,6 @@ b_host:
if (hcd)
hcd->self.is_b_host = 0;
}
- break;
}
musb_host_poke_root_hub(musb);
@@ -787,7 +785,6 @@ b_host:
default:
WARNING("unhandled DISCONNECT transition (%s)\n",
usb_otg_state_string(musb->xceiv->state));
- break;
}
}
@@ -2015,7 +2012,6 @@ musb_init_controller(struct device *dev, int nIrq, void __iomem *ctrl)
break;
default:
dev_err(dev, "unsupported port mode %d\n", musb->port_mode);
- break;
}
if (status < 0)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/9] usb: phy: am335x: group the #includes by subdirs
From: Lothar Waßmann @ 2014-07-18 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405675890-8802-2-git-send-email-LW@KARO-electronics.de>
Signed-off-by: Lothar Wa?mann <LW@KARO-electronics.de>
---
drivers/usb/phy/phy-am335x.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/phy/phy-am335x.c b/drivers/usb/phy/phy-am335x.c
index b70e055..91c71ab 100644
--- a/drivers/usb/phy/phy-am335x.c
+++ b/drivers/usb/phy/phy-am335x.c
@@ -1,13 +1,13 @@
#include <linux/module.h>
#include <linux/platform_device.h>
#include <linux/dma-mapping.h>
-#include <linux/usb/otg.h>
-#include <linux/usb/usb_phy_generic.h>
#include <linux/slab.h>
#include <linux/clk.h>
-#include <linux/regulator/consumer.h>
#include <linux/of.h>
#include <linux/of_address.h>
+#include <linux/regulator/consumer.h>
+#include <linux/usb/otg.h>
+#include <linux/usb/usb_phy_generic.h>
#include "am35x-phy-control.h"
#include "phy-generic.h"
--
1.7.10.4
^ permalink raw reply related
* [PATCH 3/9] usb: musb_am335x: source cleanup
From: Lothar Waßmann @ 2014-07-18 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405675890-8802-3-git-send-email-LW@KARO-electronics.de>
- remove comma after end of list delimiter
The empty entry must always be the last item in the list, thus there
is no point in having a trailing comma to facilitate adding
succeding entries.
Remove the comma, so that inadvertedly adding an entry after the end
of list sentinel will produce a compile time error rather than an
unreachable entry in the list.
- consistently use tabs for indentation
Signed-off-by: Lothar Wa?mann <LW@KARO-electronics.de>
---
drivers/usb/musb/musb_am335x.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/usb/musb/musb_am335x.c b/drivers/usb/musb/musb_am335x.c
index 1e58ed2..164c868 100644
--- a/drivers/usb/musb/musb_am335x.c
+++ b/drivers/usb/musb/musb_am335x.c
@@ -21,14 +21,14 @@ err:
static const struct of_device_id am335x_child_of_match[] = {
{ .compatible = "ti,am33xx-usb" },
- { },
+ { }
};
MODULE_DEVICE_TABLE(of, am335x_child_of_match);
static struct platform_driver am335x_child_driver = {
.probe = am335x_child_probe,
- .driver = {
- .name = "am335x-usb-childs",
+ .driver = {
+ .name = "am335x-usb-childs",
.of_match_table = am335x_child_of_match,
},
};
--
1.7.10.4
^ permalink raw reply related
* [PATCH 4/9] usb: phy: am335x-control: prevent module from being unloaded when in use
From: Lothar Waßmann @ 2014-07-18 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405675890-8802-4-git-send-email-LW@KARO-electronics.de>
This patch fixes the real cause of the crash that was "fixed" by
commit 7adb5c876e9c usb: musb: Fix panic upon musb_am335x module removal
Signed-off-by: Lothar Wa?mann <LW@KARO-electronics.de>
---
drivers/usb/phy/phy-am335x-control.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/usb/phy/phy-am335x-control.c b/drivers/usb/phy/phy-am335x-control.c
index 35b6083..df3e1ba 100644
--- a/drivers/usb/phy/phy-am335x-control.c
+++ b/drivers/usb/phy/phy-am335x-control.c
@@ -140,6 +140,9 @@ static int am335x_control_usb_probe(struct platform_device *pdev)
const struct of_device_id *of_id;
const struct phy_control *phy_ctrl;
+ if (!try_module_get(pdev->dev.parent->driver->owner))
+ return -EPROBE_DEFER;
+
of_id = of_match_node(omap_control_usb_id_table, pdev->dev.of_node);
if (!of_id)
return -EINVAL;
@@ -171,8 +174,15 @@ static int am335x_control_usb_probe(struct platform_device *pdev)
return 0;
}
+static int am335x_control_usb_remove(struct platform_device *pdev)
+{
+ module_put(pdev->dev.parent->driver->owner);
+ return 0;
+}
+
static struct platform_driver am335x_control_driver = {
.probe = am335x_control_usb_probe,
+ .remove = am335x_control_usb_remove,
.driver = {
.name = "am335x-control-usb",
.owner = THIS_MODULE,
--
1.7.10.4
^ permalink raw reply related
* [PATCH 5/9] usb: musb: print error message with dev_err() instead of dev_dbg()
From: Lothar Waßmann @ 2014-07-18 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405675890-8802-5-git-send-email-LW@KARO-electronics.de>
Signed-off-by: Lothar Wa?mann <LW@KARO-electronics.de>
---
drivers/usb/musb/musb_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index 8623112..f867b44 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1878,7 +1878,7 @@ musb_init_controller(struct device *dev, int nIrq, void __iomem *ctrl)
* Fail when the board needs a feature that's not enabled.
*/
if (!plat) {
- dev_dbg(dev, "no platform_data?\n");
+ dev_err(dev, "no platform_data?\n");
status = -ENODEV;
goto fail0;
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH 6/9] usb: musb: core: properly setup the HW before registering it to the USB core
From: Lothar Waßmann @ 2014-07-18 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405675890-8802-6-git-send-email-LW@KARO-electronics.de>
Without this patch overriding the USBOTG_ID pin by setting the iddig
bit in the USB_MODE register doesn't work because it happens too late
to be recognized correctly.
Signed-off-by: Lothar Wa?mann <LW@KARO-electronics.de>
---
drivers/usb/musb/musb_core.c | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/musb/musb_core.c b/drivers/usb/musb/musb_core.c
index f867b44..bbf2aefb 100644
--- a/drivers/usb/musb/musb_core.c
+++ b/drivers/usb/musb/musb_core.c
@@ -1988,18 +1988,21 @@ musb_init_controller(struct device *dev, int nIrq, void __iomem *ctrl)
switch (musb->port_mode) {
case MUSB_PORT_MODE_HOST:
- status = musb_host_setup(musb, plat->power);
+ status = musb_platform_set_mode(musb, MUSB_HOST);
if (status < 0)
goto fail3;
- status = musb_platform_set_mode(musb, MUSB_HOST);
+ status = musb_host_setup(musb, plat->power);
break;
case MUSB_PORT_MODE_GADGET:
- status = musb_gadget_setup(musb);
+ status = musb_platform_set_mode(musb, MUSB_PERIPHERAL);
if (status < 0)
goto fail3;
- status = musb_platform_set_mode(musb, MUSB_PERIPHERAL);
+ status = musb_gadget_setup(musb);
break;
case MUSB_PORT_MODE_DUAL_ROLE:
+ status = musb_platform_set_mode(musb, MUSB_OTG);
+ if (status < 0)
+ goto fail3;
status = musb_host_setup(musb, plat->power);
if (status < 0)
goto fail3;
@@ -2008,7 +2011,6 @@ musb_init_controller(struct device *dev, int nIrq, void __iomem *ctrl)
musb_host_cleanup(musb);
goto fail3;
}
- status = musb_platform_set_mode(musb, MUSB_OTG);
break;
default:
dev_err(dev, "unsupported port mode %d\n", musb->port_mode);
--
1.7.10.4
^ permalink raw reply related
* [PATCH 7/9] usb: phy: am335x: setup the gen_phy function pointers _before_ adding the phy
From: Lothar Waßmann @ 2014-07-18 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405675890-8802-7-git-send-email-LW@KARO-electronics.de>
Make sure all parameters are correctly set up before registering the
PHY with the USB framework.
Signed-off-by: Lothar Wa?mann <LW@KARO-electronics.de>
---
drivers/usb/phy/phy-am335x.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/usb/phy/phy-am335x.c b/drivers/usb/phy/phy-am335x.c
index 91c71ab..6522fa7 100644
--- a/drivers/usb/phy/phy-am335x.c
+++ b/drivers/usb/phy/phy-am335x.c
@@ -56,11 +56,12 @@ static int am335x_phy_probe(struct platform_device *pdev)
if (ret)
return ret;
+ am_phy->usb_phy_gen.phy.init = am335x_init;
+ am_phy->usb_phy_gen.phy.shutdown = am335x_shutdown;
+
ret = usb_add_phy_dev(&am_phy->usb_phy_gen.phy);
if (ret)
return ret;
- am_phy->usb_phy_gen.phy.init = am335x_init;
- am_phy->usb_phy_gen.phy.shutdown = am335x_shutdown;
platform_set_drvdata(pdev, am_phy);
device_init_wakeup(dev, true);
--
1.7.10.4
^ permalink raw reply related
* [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-18 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405675890-8802-8-git-send-email-LW@KARO-electronics.de>
This patch makes it possible to use the musb driver with HW that
requires external regulators or clocks.
Signed-off-by: Lothar Wa?mann <LW@KARO-electronics.de>
---
drivers/usb/phy/phy-am335x.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/usb/phy/phy-am335x.c b/drivers/usb/phy/phy-am335x.c
index 6522fa7..de25674 100644
--- a/drivers/usb/phy/phy-am335x.c
+++ b/drivers/usb/phy/phy-am335x.c
@@ -22,6 +22,7 @@ static int am335x_init(struct usb_phy *phy)
{
struct am335x_phy *am_phy = dev_get_drvdata(phy->dev);
+ usb_gen_phy_init(phy);
phy_ctrl_power(am_phy->phy_ctrl, am_phy->id, true);
return 0;
}
@@ -31,6 +32,7 @@ static void am335x_shutdown(struct usb_phy *phy)
struct am335x_phy *am_phy = dev_get_drvdata(phy->dev);
phy_ctrl_power(am_phy->phy_ctrl, am_phy->id, false);
+ usb_gen_phy_shutdown(phy);
}
static int am335x_phy_probe(struct platform_device *pdev)
--
1.7.10.4
^ permalink raw reply related
* [PATCH 9/9] usb: musb: musb_am335x: reinstate module loading/unloading support
From: Lothar Waßmann @ 2014-07-18 9:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405675890-8802-9-git-send-email-LW@KARO-electronics.de>
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.
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);
+ return 0;
+}
+
+static int am335x_child_remove(struct platform_device *pdev)
+{
+ device_for_each_child(&pdev->dev, NULL, of_remove_populated_child);
+ pm_runtime_disable(&pdev->dev);
+ return 0;
+}
+
static const struct of_device_id am335x_child_of_match[] = {
{ .compatible = "ti,am33xx-usb" },
{ }
@@ -27,17 +43,14 @@ MODULE_DEVICE_TABLE(of, am335x_child_of_match);
static struct platform_driver am335x_child_driver = {
.probe = am335x_child_probe,
+ .remove = am335x_child_remove,
.driver = {
.name = "am335x-usb-childs",
.of_match_table = am335x_child_of_match,
},
};
-static int __init am335x_child_init(void)
-{
- return platform_driver_register(&am335x_child_driver);
-}
-module_init(am335x_child_init);
+module_platform_driver(am335x_child_driver);
MODULE_DESCRIPTION("AM33xx child devices");
MODULE_LICENSE("GPL v2");
--
1.7.10.4
^ permalink raw reply related
* [PATCH v2 6/7] ARM: dts: rockchip: add core rk3288 dtsi
From: Mark Rutland @ 2014-07-18 9:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <14646641.DlFrJR068n@diego>
Hi Heiko,
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + cpu at 500 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a12";
> + reg = <0x500>;
> + };
> + cpu at 501 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a12";
> + reg = <0x501>;
> + };
> + cpu at 502 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a12";
> + reg = <0x502>;
> + };
> + cpu at 503 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a12";
> + reg = <0x503>;
I take it that we can only use one of these for the moment? I didn't see
the addition of any SMP code.
Or did I miss that?
[...]
> + timer {
> + compatible = "arm,armv7-timer";
> + interrupts = <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> + <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> + <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>,
> + <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> + clock-frequency = <24000000>;
> + };
Please say you don't need this clock-frequency property.
It's a work-around at best, and you won't be able to use Hyp properly.
I'd really like to discourage use of this property, especially as people
seem to set it regardless of whether the hardware's correct...
What's the state of CNTFREQ and CNTVOFF, and is there any chance that
these are sane?
Cheers,
Mark.
^ permalink raw reply
* [PATCHv6 0/4] iio: adc: exynos_adc: Support Exynos3250 ADC and code clean
From: Arnd Bergmann @ 2014-07-18 9:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405663186-26464-1-git-send-email-cw00.choi@samsung.com>
On Friday 18 July 2014 14:59:42 Chanwoo Choi wrote:
> This patchset support Exynos3250 ADC (Analog Digital Converter) because
> Exynos3250 has additional special clock for ADC IP.
>
by coincidence, I have just looked at the same driver in order to
add support for s3c24xx and s3c64xx, so we can remove the plat-samsung
adc framework they still use. Those changes would naturally conflict
with yours, but I think it makes sense for your patches to come first.
I'll comment a bit more on the individual patches. I didn't have
interest in them earlier, so I didn't comment so far.
Another aspect that came up is the touchscreen support. Right now,
there is drivers/input/touchscreen/s3c2410_ts.c which is intimately
tied to arch/arm/plat-samsung/adc.c. The best way forward (as discussed
on IRC as few days ago) seems to be to integrate support for that into
the exynos_adc driver. Can you comment on which parts actually support
touchscreen? Did touchscreen support get dropped in the exynos hardware,
or is the driver just missing at the moment?
Arnd
^ permalink raw reply
* [PATCHv6 1/4] iio: adc: exynos_adc: Add exynos_adc_data structure to improve readability
From: Arnd Bergmann @ 2014-07-18 9:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405663186-26464-2-git-send-email-cw00.choi@samsung.com>
On Friday 18 July 2014 14:59:43 Chanwoo Choi wrote:
> This patchset add 'exynos_adc_data' structure which includes some functions
> to control ADC operation and specific data according to ADC version (v1 or v2).
>
This new structure makes a lot of sense for covering the exynos specific
versions, but it will likely give a little more complexity for the
older models. We'll have to deal with that later then, no need to
hold up your patch. Interestingly, the version numbers seem weird. The
old driver uses
{
.name = "s3c24xx-adc",
.driver_data = TYPE_ADCV1,
}, {
.name = "s3c2443-adc",
.driver_data = TYPE_ADCV11,
}, {
.name = "s3c2416-adc",
.driver_data = TYPE_ADCV12,
}, {
.name = "s3c64xx-adc",
.driver_data = TYPE_ADCV2,
}, {
.name = "samsung-adc-v3",
.driver_data = TYPE_ADCV3,
}
Where TYPE_ADCV3 seems to be the same as the new ADC_V1 used in this
driver. Do you have an explanation for that?
Arnd
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox