* [PATCH] ARM: dts: add CPU nodes for Exynos4 SoCs
From: Daniel Drake @ 2014-07-21 12:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1863399.9O2S91ZvEO@amdc1032>
On Fri, Jul 18, 2014 at 5:00 PM, Bartlomiej Zolnierkiewicz
<b.zolnierkie@samsung.com> wrote:
> Recent patch by Tomasz Figa ("irqchip: gic: Fix core ID calculation
> when topology is read from DT") fixed GIC driver to filter cluster ID
> from values returned by cpu_logical_map() for SoCs having registers
> mapped without per-CPU banking making it is possible to add CPU nodes
> for Exynos4 SoCs. In case of Exynos SoCs these CPU nodes are also
> required by future changes adding initialization of cpuidle states in
> Exynos cpuidle driver through DT.
This conflicts with work in the thread "cpufreq: use generic cpufreq
drivers for exynos platforms" which is already in its 7th iteration.
Perhaps best to work directly with Thomas to help him finish that series?
Daniel
^ permalink raw reply
* [PATCH] spi: omap2-mcspi: fix blatant abuse of the resource subsystem
From: Lothar Waßmann @ 2014-07-21 12:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721121820.GW17528@sirena.org.uk>
Hi,
Mark Brown wrote:
> On Mon, Jul 21, 2014 at 07:51:44AM +0200, Lothar Wa?mann wrote:
> > Mark Brown wrote:
>
> > > I'm not going to apply this with a commit message such as the above.
> > > Quite aside from the tone the fact that it doesn't describe the issue
> > > is not helpful for review, one of the things done in review is to try to
> > > check that the change has the intended effect.
>
> > Maybe the original author or the maintainer who accepted this can come
> > up with a decent fix for this.
>
> Just to be clear the issue is with the presentation of your change, it
> is not appropriate to provide a changelog which consists mainly of
> widely directed personal insults especially given that it omits basic
> technical content.
>
I understood that, but I feel incapable to come up with a reasonable
changelog for this.
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 00/11] pwm: Introduce ST's PWM driver
From: Lee Jones @ 2014-07-21 12:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405348412-7352-1-git-send-email-lee.jones@linaro.org>
Hi Thierry,
Did you find some time to look at this set?
> I'm pretty sure all of your review comments have been tended to
> now. Some have been fixed-up by myself and re-rolled into the
> original set. The larger changes have been fixed as subsequent
> patches for ease of review and history tracking on the internal
> kernel.
>
> Kind regards,
> Lee
>
> Ajit Pal Singh (4):
> pwm: st: Fix PWM prescaler handling
> pwm: sti: Ensure same period values for all channels
> pwm: sti: Sync between enable/disable calls
> pwm: sti: Remove PWM period table
>
> Lee Jones (7):
> ARM: stih407: Add DT nodes for for PWM
> ARM: stih416: Add Pinctrl settings for PWM
> ARM: stih416: Add DT nodes for PWM
> ARM: stih416-b2020e: Enable PWM on the B2020 Rev-E
> ARM: multi_v7_defconfig: Enable ST's PWM driver
> pwm: sti: Add new driver for ST's PWM IP
> pwm: sti: Supply Device Tree binding documentation for ST's PWM IP
>
> Documentation/devicetree/bindings/pwm/pwm-st.txt | 41 +++
> arch/arm/boot/dts/stih407.dtsi | 28 ++
> arch/arm/boot/dts/stih416-b2020e.dts | 10 +
> arch/arm/boot/dts/stih416-pinctrl.dtsi | 50 +++
> arch/arm/boot/dts/stih416.dtsi | 44 ++-
> arch/arm/configs/multi_v7_defconfig | 1 +
> drivers/pwm/Kconfig | 10 +
> drivers/pwm/Makefile | 1 +
> drivers/pwm/pwm-sti.c | 418 +++++++++++++++++++++++
> 9 files changed, 602 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/devicetree/bindings/pwm/pwm-st.txt
> create mode 100644 drivers/pwm/pwm-sti.c
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCHv2 12/17] cpuidle: mvebu: make the cpuidle driver capable of handling multiple SoCs
From: Thomas Petazzoni @ 2014-07-21 12:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <53CD08CF.6080900@linaro.org>
Dear Daniel Lezcano,
On Mon, 21 Jul 2014 14:34:23 +0200, Daniel Lezcano wrote:
> So there are three solutions:
>
> 1. Pass the flag through the platform data, I am not really in favor of
> that as mentioned above
That's what is already implemented.
>
> 2. Use the compatible string like the cpuidle-big-little.c driver, but
> Arnd is not in favor of that
>
> 3. Register 3 platform drivers, in cpuidle-mvebu-v7.c, and let the
> registering of the cpuidle's platform device to enable the right one
I'm fine with doing (3). Daniel, Arnd, let me know if that's ok for
you, and I'll respin the patch series accordingly.
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [RESEND PATCH v3 06/11] drm: add DT bindings documentation for atmel-hlcdc-dc driver
From: Boris BREZILLON @ 2014-07-21 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1616525.bcHvjgnZ4T@avalon>
On Mon, 21 Jul 2014 14:16:42 +0200
Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> Hi Thierry,
>
> On Monday 21 July 2014 14:12:47 Thierry Reding wrote:
> > On Mon, Jul 21, 2014 at 11:57:37AM +0200, Boris BREZILLON wrote:
> > > On Mon, 21 Jul 2014 11:32:55 +0200 Laurent Pinchart wrote:
> > >> On Monday 21 July 2014 11:24:38 Boris BREZILLON wrote:
> > >>> On Mon, 21 Jul 2014 10:59:12 +0200 Thierry Reding wrote:
> > >>>> On Fri, Jul 18, 2014 at 05:43:34PM +0200, Boris BREZILLON wrote:
> > >>>> [...]
> > >>>>
> > >>>>>>>>>> + - atmel,panel: Should contain a phandle with 2 parameters.
> > >>>>>>>>>> + The first cell is a phandle to a DRM panel device
> > >>>>>>>>>> + The second cell encodes the RGB mode, which can take the
> > >>>>>>>>>> following values:
> > >>>>>>>>>> + * 0: RGB444
> > >>>>>>>>>> + * 1: RGB565
> > >>>>>>>>>> + * 2: RGB666
> > >>>>>>>>>> + * 3: RGB888
> > >>>>>>>>>
> > >>>>>>>>> These are properties of the panel and should be obtained from
> > >>>>>>>>> the panel directly rather than an additional cell in this
> > >>>>>>>>> specifier.
> > >>>>>>>>
> > >>>>>>>> Okay.
> > >>>>>>>> What's the preferred way of doing this ?
> > >>>>>>>> What about defining an rgb-mode property in the panel node.
> > >>>>>>>
> > >>>>>>> There's .bpc in struct drm_display_info, I suspect that it could
> > >>>>>>> be used for this. Alternatively, maybe we could extend the list
> > >>>>>>> of color formats that go into drm_display_info.color_formats?
> > >>>>>>> RGB444 is already covered.
> > >>>>>
> > >>>>> I forgot to ask about bpc meaning. If, as I think, it means "bits
> > >>>>> per color" then it cannot be used to encode RGB565 where green
> > >>>>> color is encoded on 6 bits and red and blue are encoded on 5 bits.
> > >>>>
> > >>>> Yes, I agree that bps is not a good fit for what you need here.
> > >>>
> > >>> Okay, then I think we can replace bpc and color_formats by a
> > >>> bus_formats table containing all supported formats, and use an enum
> > >>> (something similar to v4l2_mbus_pixelcode defined in v4l2-mediabus.h
> > >>> [1]) to list the available formats.
> > >>>
> > >>> As this implies quite a few changes in crtc core and some drm drivers
> > >>> (nouveau, i915 and radeon), I'd like to be sure this is what both of
> > >>> you had in mind.
> > >>
> > >> I think it is, but just to make sure I understand you correctly, could
> > >> you just show how the drm_display_info structure would look like ?
> > >
> > > The new drm_display_info structure should look like this [2] (except
> > > that color_formats and bpc have not be removed yet), and [1] is just
> > > here to show how the video_bus_format enum would look like.
> > >
> > > [1] http://code.bulix.org/rfd0yx-86557
> > > [2] http://code.bulix.org/7n03b4-86556
> >
> > Quoting from your paste:
> >
> > + const enum video_bus_format *bus_formats;
> > + int nbus_formats;
> >
> > Do we really need more than one?
>
> We do if we want to replace the color_formats and bpc fields.
>
Yes, that's what I was about to answer :-).
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [PATCHv2 12/17] cpuidle: mvebu: make the cpuidle driver capable of handling multiple SoCs
From: Daniel Lezcano @ 2014-07-21 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721140917.16e71558@free-electrons.com>
On 07/21/2014 02:09 PM, Thomas Petazzoni wrote:
> Dear Arnd Bergmann,
>
> On Mon, 21 Jul 2014 14:00:22 +0200, Arnd Bergmann wrote:
>
>> I don't know, it really depends on what the differences are between
>> the SoCs, and I haven't looked at them.
>>
>> Using the compatible strings would make it work best if you have one
>> driver per variant, and then share some common code, as opposed to
>> having one shared driver with a number of exceptions.
>>
>> If the differences are just a few parameters, it might be better
>> to encode those parameters in DT properties instead.
>
> The differences are in the cpuidle states that are supported, see
> patches "cpuidle: mvebu: add Armada 370 support" and "cpuidle: mvebu:
> add Armada 38x support" in the series.
>
> I honestly believe that since cpuidle functionality is not described in
> the Device Tree and therefore probed using a statically defined
> platform_device, the good way to pass these informations is to simply
> use platform_data.
Ok, so for the record the cpuidle functionality described via DT is
under discussion [1].
I understand you need several drivers for the different SoC because of
the different latencies.
I admit passing an extra flag via the platform_data is a valid approach
but I have been unifying the different drivers across the existing SoC
and there is still a lot of things to do. So accepting this patch brings
another way to discriminate the SoC variant I would like to avoid.
Due the different latencies, I don't think the DT property is enough and
that may enter in conflict with Lorenzo's work.
So there are three solutions:
1. Pass the flag through the platform data, I am not really in favor of
that as mentioned above
2. Use the compatible string like the cpuidle-big-little.c driver, but
Arnd is not in favor of that
3. Register 3 platform drivers, in cpuidle-mvebu-v7.c, and let the
registering of the cpuidle's platform device to enable the right one
[1] http://www.spinics.net/lists/arm-kernel/msg341541.html
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
^ permalink raw reply
* [RESEND PATCH v3 06/11] drm: add DT bindings documentation for atmel-hlcdc-dc driver
From: Boris BREZILLON @ 2014-07-21 12:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721121513.GB15238@ulmo>
On Mon, 21 Jul 2014 14:15:16 +0200
Thierry Reding <thierry.reding@gmail.com> wrote:
> On Fri, Jul 18, 2014 at 04:51:52PM +0200, Boris BREZILLON wrote:
> > Hi Thierry,
> >
> > Oops, I missed this reply.
> >
> > On Tue, 15 Jul 2014 12:31:37 +0200
> > Thierry Reding <thierry.reding@gmail.com> wrote:
> >
> > > On Tue, Jul 15, 2014 at 12:06:19PM +0200, Boris BREZILLON wrote:
> > > > On Mon, 14 Jul 2014 12:05:43 +0200 Thierry Reding <thierry.reding@gmail.com> wrote:
> > > > > On Mon, Jul 07, 2014 at 06:42:59PM +0200, Boris BREZILLON wrote:
> > > [...]
> > > > > > diff --git a/Documentation/devicetree/bindings/drm/atmel-hlcdc-dc.txt b/Documentation/devicetree/bindings/drm/atmel-hlcdc-dc.txt
> > > > > [...]
> > > > > > +The Atmel HLCDC Display Controller is subdevice of the HLCDC MFD device.
> > > > > > +See Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt for more details.
> > > > >
> > > > > I think it's better to refer to these using relative filenames. When the
> > > > > device tree bindings are moved out of the kernel tree, they may no
> > > > > longer use the same hierarchy.
> > > >
> > > > Sure.
> > > > By relative path you mean ../../mfd/atmel-hlcdc.txt or just
> > > > mfd/atmel-hlcdc.txt ?
> > >
> > > I think the former is more explicit.
> >
> > Okay.
> >
> > >
> > > > > > + - atmel,panel: Should contain a phandle with 2 parameters.
> > > > > > + The first cell is a phandle to a DRM panel device
> > > > > > + The second cell encodes the RGB mode, which can take the following values:
> > > > > > + * 0: RGB444
> > > > > > + * 1: RGB565
> > > > > > + * 2: RGB666
> > > > > > + * 3: RGB888
> > > > >
> > > > > These are properties of the panel and should be obtained from the panel
> > > > > directly rather than an additional cell in this specifier.
> > > >
> > > > Okay.
> > > > What's the preferred way of doing this ?
> > > > What about defining an rgb-mode property in the panel node.
> > >
> > > There's .bpc in struct drm_display_info, I suspect that it could be used
> > > for this. Alternatively, maybe we could extend the list of color formats
> > > that go into drm_display_info.color_formats? RGB444 is already covered.
> >
> > I don't think this color_formats field is intended to represent data
> > stream format going through the bus.
> > Moreover, AFAIU, RGB444 in this definition represent RGB 4:4:4 (chroma
> > subsampling rate) and not 12 bits signals (4 bits for each color).
> >
> > Anyway I'll propose a patch series adding a new field to
> > drm_display_info to encode the mediabus format (as discussed with
> > Laurent and you).
> >
> > >
> > > Also, like Laurent said, this shouldn't go into the device tree, since
> > > it's already implied by the panel's compatible value, so we'd be
> > > duplicating information.
> >
> > Again, this is not necessarily true (depending on your board design).
> > One can decide to connect an RGB888 panel on an RGB666 bus and connect
> > the missing pins to ground.
>
> I think in that case the board design itself could be considered as an
> RGB888 to RGB666 bridge, and I think that's what the device tree should
> be describing rather than a panel with a variable number of input
> formats.
So, you're suggesting to add an RGB to RGB drm_bridge driver (and
the appropriate DT bindings) to handle this case, right ?
I don't know much about drm bridges, but I'll take a look.
Anyway, at the moment I don't have such hardware (one connecting an
RGB888 panel on an RGB666 bus), I was just wondering how I could
represent it ;-).
Thanks,
Boris
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* [RFC PATCH 4/7] ARM: OMAP4+: PRM: register interrupt information from DT
From: Tony Lindgren @ 2014-07-21 12:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGo_u6q21_z-+mTWFD2T36mAXahwZt8-GBH0J3yuy+11CLYbxA@mail.gmail.com>
* Nishanth Menon <nm@ti.com> [140721 05:11]:
> On Mon, Jul 21, 2014 at 6:28 AM, Tony Lindgren <tony@atomide.com> wrote:
> > * Nishanth Menon <nm@ti.com> [140721 04:24]:
> >> On Mon, Jul 21, 2014 at 5:51 AM, Tony Lindgren <tony@atomide.com> wrote:
> >> >
> >> >> +static struct of_device_id omap_prm_dt_match_table[] = {
> >> >> + { .compatible = "ti,omap4-prm" },
> >> >> + { .compatible = "ti,omap5-prm" },
> >> >> + { .compatible = "ti,dra7-prm" },
> >> >> + { }
> >> >> +};
> >> >> +
> >> >
> >> > I'd like to avoid adding more driver like stuff to mach-omap2
> >> > and parsing compatible flags and dealing with interupts sounds
> >> > very driver like.. But maybe just the handling can be moved
> >> > out?
> >>
> >> I understand your view, but, Handling of interrupts is already in
> >> place even now in mach-omap2. Currently the prm devices are handled by
> >> mach-omap2 and all this does it to prevent hardcoding of irq numbers
> >> within the current code.
> >
> > Yeah but at a cost of no dev entry, no probe etc. I'd rather keep
> > that SoC specific data around until a driver can deal with it
> > in a standard way.
> >
> >> > Would a simple driver be doable that parses the compatible
> >> > flags, takes care of the IRQ chaining, and gets some SoC specific
> >> > function pointers as auxdata?
> >>
> >> Tero has been trying to move PRM/CM stuff to a separate drivers of
> >> thier own. With that there wont be a need for auxdata even. - this
> >> current logic will get merged with that driver - if and when that is
> >> ready. I am not actually adding any driver logic here - just reusing
> >> the logic and providing glue for using dt description instead of
> >> hardcoded logic that the current mach-omap2 driver does.
> >
> > Well how about let's just leave out the non-standard parts for
> > now, then once the PRM/CM driver can deal with, it can do things
> > in a normal way?
>
> Broken PRCM interrupt handling for DRA7. but if you like to state
> which parts are ok, I can probably repost with just those and leave
> the rest for when ever PRM / CM driver happens to work out (and as a
> result keep DRA7 daisy chain support broken till then - so probably
> blocking low power features such as suspend-to-ram till that work is
> complete.).
Well if Tero is fine with this approach, looks OK for me. At least
the .dts entries should work in the long run.
Regards,
Tony
^ permalink raw reply
* [PATCH v5 0/7] kernel: Add support for restart handler call chain
From: Catalin Marinas @ 2014-07-21 12:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405668856-13738-1-git-send-email-linux@roeck-us.net>
On Fri, Jul 18, 2014 at 08:34:09AM +0100, Guenter Roeck wrote:
> Patch 1 of this series implements the restart handler function. Patches 2 and 3
> implement calling the restart handler chain from arm and arm64 restart code.
>
> Patch 4 modifies the restart-poweroff driver to no longer call arm_pm_restart
> directly but machine_restart. This is done to avoid calling arm_pm_restart
> from more than one place. The change makes the driver architecture independent,
> so it would be possible to drop the arm dependency from its Kconfig entry.
>
> Patch 5 and 6 convert existing restart handlers in the watchdog subsystem
> to use the restart handler. Patch 7 unexports arm_pm_restart to ensure
> that no one gets the idea to implement a restart handler as module.
For the current patches:
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Do you plan to convert more of the power/drivers/reset/ code?
BTW, is it worth doing something similar for pm_power_off (there is
generic code calling it directly, so slightly more complicated than
pm_restart)?
^ permalink raw reply
* [GIT PULL] omap soc clean-up for v3.17 merge window
From: Tony Lindgren @ 2014-07-21 12:30 UTC (permalink / raw)
To: linux-arm-kernel
The following changes since commit cd3de83f147601356395b57a8673e9c5ff1e59d1:
Linux 3.16-rc4 (2014-07-06 12:37:51 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.17/soc-cleanup
for you to fetch changes up to 3db53918e306d3960bf9e12eea8b2fd3f7d0fd62:
Merge tag 'for-v3.17/omap-clock-a' of git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending into omap-for-v3.17/soc (2014-07-21 00:35:38 -0700)
----------------------------------------------------------------
SoC specific omap clean-up for v3.17 merge window:
- Changes to PRM and clock related code to help move
things to drivers
- Removal of unused ctrl module defines that no longer
are needed with things moving to .dts files and
drivers
----------------------------------------------------------------
Joachim Eastwood (1):
ARM: OMAP4: Ctrl module register define diet
Tero Kristo (22):
ARM: OMAP3: PRM: move prcm wakeup helper to prm driver
ARM: OMAP3: PRM: move iva reset to PRM driver
ARM: OMAP3: PRM: move modem reset to PRM driver
ARM: OMAP3: PRM: add API for checking and clearing cold reset status
ARM: OMAP3: PRM: add API for saving PRM scratchpad contents
ARM: OMAP24xx: PRM: add API for clearing wakeup status bits
ARM: OMAP3: PRM: move PRM init code from PM core to the driver
ARM: OMAP3: control: add API for setting up the modem pads
ARM: OMAP3: PRM: move modem reset and iva2 idle to PRM driver
ARM: OMAP3: control: isolate control module init to its own function
ARM: OMAP4+: clock: remove DEFINE_CLK_OMAP_HSDIVIDER macro
ARM: OMAP4+: dpll: remove cpu_is_omap44xx checks
ARM: OMAP4+: dpll44xx: remove cm-regbits-44xx.h and clock44xx.h includes
ARM: OMAP2+: clock: introduce ti_clk_features flags
ARM: OMAP2+: clock: add fint values to the ti_clk_features struct
ARM: OMAP2+: clock/dpll: add private API for checking if DPLL is in bypass
ARM: OMAP2+: clock/dpll: convert bypass check to use clk_features
ARM: OMAP2+: clock/dpll: add jitter correction behind clk_features
ARM: OMAP2+: clock/interface: add a clk_features definition for idlest value
ARM: OMAP2+: clock/dpll: remove unused header includes from clkt_dpll.c
ARM: OMAP2+: clock/dpll: remove unused header includes from dpll3xxx.c
ARM: OMAP2+: clock/interface: remove some headers from clkt_iclk.c file
Tony Lindgren (2):
Merge branch 'for-v3.17/cm-prm-cleanup' of https://github.com/t-kristo/linux-pm into omap-for-v3.17/soc
Merge tag 'for-v3.17/omap-clock-a' of git://git.kernel.org/.../pjw/omap-pending into omap-for-v3.17/soc
arch/arm/mach-omap2/clkt_dpll.c | 98 +-
arch/arm/mach-omap2/clkt_iclk.c | 8 +-
arch/arm/mach-omap2/clock.c | 76 +-
arch/arm/mach-omap2/clock.h | 44 +-
arch/arm/mach-omap2/control.c | 60 +-
arch/arm/mach-omap2/control.h | 40 +-
arch/arm/mach-omap2/ctrl_module_core_44xx.h | 392 -------
arch/arm/mach-omap2/ctrl_module_pad_core_44xx.h | 1409 -----------------------
arch/arm/mach-omap2/ctrl_module_pad_wkup_44xx.h | 236 ----
arch/arm/mach-omap2/dpll3xxx.c | 7 +-
arch/arm/mach-omap2/dpll44xx.c | 19 +-
arch/arm/mach-omap2/io.c | 2 +
arch/arm/mach-omap2/pm24xx.c | 31 +-
arch/arm/mach-omap2/pm34xx.c | 218 +---
arch/arm/mach-omap2/prm2xxx.c | 18 +
arch/arm/mach-omap2/prm2xxx.h | 1 +
arch/arm/mach-omap2/prm3xxx.c | 233 ++++
arch/arm/mach-omap2/prm3xxx.h | 6 +
18 files changed, 516 insertions(+), 2382 deletions(-)
delete mode 100644 arch/arm/mach-omap2/ctrl_module_core_44xx.h
delete mode 100644 arch/arm/mach-omap2/ctrl_module_pad_core_44xx.h
delete mode 100644 arch/arm/mach-omap2/ctrl_module_pad_wkup_44xx.h
^ permalink raw reply
* [PATCH 1/1] ahci: st: Provide DT bindings for ST's SATA implementation
From: Tejun Heo @ 2014-07-21 12:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1405931316-12276-1-git-send-email-lee.jones@linaro.org>
On Mon, Jul 21, 2014 at 09:28:36AM +0100, Lee Jones wrote:
> Cc: devicetree at vger.kernel.org
> Cc: Srinivas Kandagatla <srinivas.kandagatla@st.com>
> Acked-by: Alexandre Torgue <alexandre.torgue@st.com>
> Signed-off-by: Lee Jones <lee.jones@linaro.org>
> ---
>
> Hi Tejun,
>
> This patch has been on the MLs for a few months now. It documents
> ST's AHCI driver which was accepted by you and now resides in
> Mainline.
Sorry about that. Applied to libata/for-3.17.
Thanks.
--
tejun
^ permalink raw reply
* [PATCH] spi: omap2-mcspi: fix blatant abuse of the resource subsystem
From: Mark Brown @ 2014-07-21 12:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721075144.251bb67d@ipc1.ka-ro>
On Mon, Jul 21, 2014 at 07:51:44AM +0200, Lothar Wa?mann wrote:
> Mark Brown wrote:
> > I'm not going to apply this with a commit message such as the above.
> > Quite aside from the tone the fact that it doesn't describe the issue
> > is not helpful for review, one of the things done in review is to try to
> > check that the change has the intended effect.
> Maybe the original author or the maintainer who accepted this can come
> up with a decent fix for this.
Just to be clear the issue is with the presentation of your change, it
is not appropriate to provide a changelog which consists mainly of
widely directed personal insults especially given that it omits basic
technical content.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140721/60630cbb/attachment.sig>
^ permalink raw reply
* [RESEND PATCH v3 06/11] drm: add DT bindings documentation for atmel-hlcdc-dc driver
From: Laurent Pinchart @ 2014-07-21 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721121245.GA15238@ulmo>
Hi Thierry,
On Monday 21 July 2014 14:12:47 Thierry Reding wrote:
> On Mon, Jul 21, 2014 at 11:57:37AM +0200, Boris BREZILLON wrote:
> > On Mon, 21 Jul 2014 11:32:55 +0200 Laurent Pinchart wrote:
> >> On Monday 21 July 2014 11:24:38 Boris BREZILLON wrote:
> >>> On Mon, 21 Jul 2014 10:59:12 +0200 Thierry Reding wrote:
> >>>> On Fri, Jul 18, 2014 at 05:43:34PM +0200, Boris BREZILLON wrote:
> >>>> [...]
> >>>>
> >>>>>>>>>> + - atmel,panel: Should contain a phandle with 2 parameters.
> >>>>>>>>>> + The first cell is a phandle to a DRM panel device
> >>>>>>>>>> + The second cell encodes the RGB mode, which can take the
> >>>>>>>>>> following values:
> >>>>>>>>>> + * 0: RGB444
> >>>>>>>>>> + * 1: RGB565
> >>>>>>>>>> + * 2: RGB666
> >>>>>>>>>> + * 3: RGB888
> >>>>>>>>>
> >>>>>>>>> These are properties of the panel and should be obtained from
> >>>>>>>>> the panel directly rather than an additional cell in this
> >>>>>>>>> specifier.
> >>>>>>>>
> >>>>>>>> Okay.
> >>>>>>>> What's the preferred way of doing this ?
> >>>>>>>> What about defining an rgb-mode property in the panel node.
> >>>>>>>
> >>>>>>> There's .bpc in struct drm_display_info, I suspect that it could
> >>>>>>> be used for this. Alternatively, maybe we could extend the list
> >>>>>>> of color formats that go into drm_display_info.color_formats?
> >>>>>>> RGB444 is already covered.
> >>>>>
> >>>>> I forgot to ask about bpc meaning. If, as I think, it means "bits
> >>>>> per color" then it cannot be used to encode RGB565 where green
> >>>>> color is encoded on 6 bits and red and blue are encoded on 5 bits.
> >>>>
> >>>> Yes, I agree that bps is not a good fit for what you need here.
> >>>
> >>> Okay, then I think we can replace bpc and color_formats by a
> >>> bus_formats table containing all supported formats, and use an enum
> >>> (something similar to v4l2_mbus_pixelcode defined in v4l2-mediabus.h
> >>> [1]) to list the available formats.
> >>>
> >>> As this implies quite a few changes in crtc core and some drm drivers
> >>> (nouveau, i915 and radeon), I'd like to be sure this is what both of
> >>> you had in mind.
> >>
> >> I think it is, but just to make sure I understand you correctly, could
> >> you just show how the drm_display_info structure would look like ?
> >
> > The new drm_display_info structure should look like this [2] (except
> > that color_formats and bpc have not be removed yet), and [1] is just
> > here to show how the video_bus_format enum would look like.
> >
> > [1] http://code.bulix.org/rfd0yx-86557
> > [2] http://code.bulix.org/7n03b4-86556
>
> Quoting from your paste:
>
> + const enum video_bus_format *bus_formats;
> + int nbus_formats;
>
> Do we really need more than one?
We do if we want to replace the color_formats and bpc fields.
--
Regards,
Laurent Pinchart
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140721/69e9ee35/attachment.sig>
^ permalink raw reply
* [RESEND PATCH v3 06/11] drm: add DT bindings documentation for atmel-hlcdc-dc driver
From: Thierry Reding @ 2014-07-21 12:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140718165152.0a9fde09@bbrezillon>
On Fri, Jul 18, 2014 at 04:51:52PM +0200, Boris BREZILLON wrote:
> Hi Thierry,
>
> Oops, I missed this reply.
>
> On Tue, 15 Jul 2014 12:31:37 +0200
> Thierry Reding <thierry.reding@gmail.com> wrote:
>
> > On Tue, Jul 15, 2014 at 12:06:19PM +0200, Boris BREZILLON wrote:
> > > On Mon, 14 Jul 2014 12:05:43 +0200 Thierry Reding <thierry.reding@gmail.com> wrote:
> > > > On Mon, Jul 07, 2014 at 06:42:59PM +0200, Boris BREZILLON wrote:
> > [...]
> > > > > diff --git a/Documentation/devicetree/bindings/drm/atmel-hlcdc-dc.txt b/Documentation/devicetree/bindings/drm/atmel-hlcdc-dc.txt
> > > > [...]
> > > > > +The Atmel HLCDC Display Controller is subdevice of the HLCDC MFD device.
> > > > > +See Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt for more details.
> > > >
> > > > I think it's better to refer to these using relative filenames. When the
> > > > device tree bindings are moved out of the kernel tree, they may no
> > > > longer use the same hierarchy.
> > >
> > > Sure.
> > > By relative path you mean ../../mfd/atmel-hlcdc.txt or just
> > > mfd/atmel-hlcdc.txt ?
> >
> > I think the former is more explicit.
>
> Okay.
>
> >
> > > > > + - atmel,panel: Should contain a phandle with 2 parameters.
> > > > > + The first cell is a phandle to a DRM panel device
> > > > > + The second cell encodes the RGB mode, which can take the following values:
> > > > > + * 0: RGB444
> > > > > + * 1: RGB565
> > > > > + * 2: RGB666
> > > > > + * 3: RGB888
> > > >
> > > > These are properties of the panel and should be obtained from the panel
> > > > directly rather than an additional cell in this specifier.
> > >
> > > Okay.
> > > What's the preferred way of doing this ?
> > > What about defining an rgb-mode property in the panel node.
> >
> > There's .bpc in struct drm_display_info, I suspect that it could be used
> > for this. Alternatively, maybe we could extend the list of color formats
> > that go into drm_display_info.color_formats? RGB444 is already covered.
>
> I don't think this color_formats field is intended to represent data
> stream format going through the bus.
> Moreover, AFAIU, RGB444 in this definition represent RGB 4:4:4 (chroma
> subsampling rate) and not 12 bits signals (4 bits for each color).
>
> Anyway I'll propose a patch series adding a new field to
> drm_display_info to encode the mediabus format (as discussed with
> Laurent and you).
>
> >
> > Also, like Laurent said, this shouldn't go into the device tree, since
> > it's already implied by the panel's compatible value, so we'd be
> > duplicating information.
>
> Again, this is not necessarily true (depending on your board design).
> One can decide to connect an RGB888 panel on an RGB666 bus and connect
> the missing pins to ground.
I think in that case the board design itself could be considered as an
RGB888 to RGB666 bridge, and I think that's what the device tree should
be describing rather than a panel with a variable number of input
formats.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140721/c0a93c42/attachment-0001.sig>
^ permalink raw reply
* [RESEND PATCH v3 06/11] drm: add DT bindings documentation for atmel-hlcdc-dc driver
From: Thierry Reding @ 2014-07-21 12:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721115737.1377a5fd@bbrezillon>
On Mon, Jul 21, 2014 at 11:57:37AM +0200, Boris BREZILLON wrote:
> On Mon, 21 Jul 2014 11:32:55 +0200
> Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
>
> > Hi Boris,
> >
> > On Monday 21 July 2014 11:24:38 Boris BREZILLON wrote:
> > > On Mon, 21 Jul 2014 10:59:12 +0200 Thierry Reding wrote:
> > > > On Fri, Jul 18, 2014 at 05:43:34PM +0200, Boris BREZILLON wrote:
> > > > [...]
> > > >
> > > >>>>>>> + - atmel,panel: Should contain a phandle with 2 parameters.
> > > >>>>>>> + The first cell is a phandle to a DRM panel device
> > > >>>>>>> + The second cell encodes the RGB mode, which can take the
> > > >>>>>>> following values:
> > > >>>>>>> + * 0: RGB444
> > > >>>>>>> + * 1: RGB565
> > > >>>>>>> + * 2: RGB666
> > > >>>>>>> + * 3: RGB888
> > > >>>>>>
> > > >>>>>> These are properties of the panel and should be obtained from
> > > >>>>>> the panel directly rather than an additional cell in this specifier.
> > > >>>>>
> > > >>>>> Okay.
> > > >>>>> What's the preferred way of doing this ?
> > > >>>>> What about defining an rgb-mode property in the panel node.
> > > >>>>
> > > >>>> There's .bpc in struct drm_display_info, I suspect that it could be
> > > >>>> used for this. Alternatively, maybe we could extend the list of color
> > > >>>> formats that go into drm_display_info.color_formats? RGB444 is already
> > > >>>> covered.
> > > >>
> > > >> I forgot to ask about bpc meaning. If, as I think, it means "bits per
> > > >> color" then it cannot be used to encode RGB565 where green color is
> > > >> encoded on 6 bits and red and blue are encoded on 5 bits.
> > > >
> > > > Yes, I agree that bps is not a good fit for what you need here.
> > >
> > > Okay, then I think we can replace bpc and color_formats by a bus_formats
> > > table containing all supported formats, and use an enum (something
> > > similar to v4l2_mbus_pixelcode defined in v4l2-mediabus.h [1]) to list
> > > the available formats.
> > >
> > > As this implies quite a few changes in crtc core and some drm drivers
> > > (nouveau, i915 and radeon), I'd like to be sure this is what both of you
> > > had in mind.
> >
> > I think it is, but just to make sure I understand you correctly, could you
> > just show how the drm_display_info structure would look like ?
> >
>
> The new drm_display_info structure should look like this [2] (except
> that color_formats and bpc have not be removed yet), and [1] is just
> here to show how the video_bus_format enum would look like.
>
> [1] http://code.bulix.org/rfd0yx-86557
> [2] http://code.bulix.org/7n03b4-86556
Quoting from your paste:
+ const enum video_bus_format *bus_formats;
+ int nbus_formats;
Do we really need more than one?
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140721/309fb551/attachment.sig>
^ permalink raw reply
* [PATCHv2 12/17] cpuidle: mvebu: make the cpuidle driver capable of handling multiple SoCs
From: Thomas Petazzoni @ 2014-07-21 12:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5251405.VTrfDi1rj5@wuerfel>
Dear Arnd Bergmann,
On Mon, 21 Jul 2014 14:00:22 +0200, Arnd Bergmann wrote:
> I don't know, it really depends on what the differences are between
> the SoCs, and I haven't looked at them.
>
> Using the compatible strings would make it work best if you have one
> driver per variant, and then share some common code, as opposed to
> having one shared driver with a number of exceptions.
>
> If the differences are just a few parameters, it might be better
> to encode those parameters in DT properties instead.
The differences are in the cpuidle states that are supported, see
patches "cpuidle: mvebu: add Armada 370 support" and "cpuidle: mvebu:
add Armada 38x support" in the series.
I honestly believe that since cpuidle functionality is not described in
the Device Tree and therefore probed using a statically defined
platform_device, the good way to pass these informations is to simply
use platform_data.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [RFC PATCH 4/7] ARM: OMAP4+: PRM: register interrupt information from DT
From: Nishanth Menon @ 2014-07-21 12:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721112807.GA18374@atomide.com>
On Mon, Jul 21, 2014 at 6:28 AM, Tony Lindgren <tony@atomide.com> wrote:
> * Nishanth Menon <nm@ti.com> [140721 04:24]:
>> On Mon, Jul 21, 2014 at 5:51 AM, Tony Lindgren <tony@atomide.com> wrote:
>> >
>> >> +static struct of_device_id omap_prm_dt_match_table[] = {
>> >> + { .compatible = "ti,omap4-prm" },
>> >> + { .compatible = "ti,omap5-prm" },
>> >> + { .compatible = "ti,dra7-prm" },
>> >> + { }
>> >> +};
>> >> +
>> >
>> > I'd like to avoid adding more driver like stuff to mach-omap2
>> > and parsing compatible flags and dealing with interupts sounds
>> > very driver like.. But maybe just the handling can be moved
>> > out?
>>
>> I understand your view, but, Handling of interrupts is already in
>> place even now in mach-omap2. Currently the prm devices are handled by
>> mach-omap2 and all this does it to prevent hardcoding of irq numbers
>> within the current code.
>
> Yeah but at a cost of no dev entry, no probe etc. I'd rather keep
> that SoC specific data around until a driver can deal with it
> in a standard way.
>
>> > Would a simple driver be doable that parses the compatible
>> > flags, takes care of the IRQ chaining, and gets some SoC specific
>> > function pointers as auxdata?
>>
>> Tero has been trying to move PRM/CM stuff to a separate drivers of
>> thier own. With that there wont be a need for auxdata even. - this
>> current logic will get merged with that driver - if and when that is
>> ready. I am not actually adding any driver logic here - just reusing
>> the logic and providing glue for using dt description instead of
>> hardcoded logic that the current mach-omap2 driver does.
>
> Well how about let's just leave out the non-standard parts for
> now, then once the PRM/CM driver can deal with, it can do things
> in a normal way?
Broken PRCM interrupt handling for DRA7. but if you like to state
which parts are ok, I can probably repost with just those and leave
the rest for when ever PRM / CM driver happens to work out (and as a
result keep DRA7 daisy chain support broken till then - so probably
blocking low power features such as suspend-to-ram till that work is
complete.).
--
---
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH 12/12] ARM: tegra: Convert PMC to a driver
From: Arnd Bergmann @ 2014-07-21 12:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140717110652.GA18383@ulmo>
On Thursday 17 July 2014 13:06:53 Thierry Reding wrote:
>
> We could go all the way and make it include/soc/tegra/*.h for better
> namespacing. I guess either way would be fine, really, since the number
> of files in those directories should be small by definition, so we
> should be able to do without the extra SoC directory, too. I have a
> slight preference for a separate SoC directory, do you have any
> objections?
I'm fine with it either way. I just noticed that you have now
moved the file, which resulted in a build error:
../drivers/ata/ahci_tegra.c:27:35: fatal error: linux/tegra-powergate.h: No such file or directory
#include <linux/tegra-powergate.h>
^
compilation terminated.
make[4]: *** [drivers/ata/ahci_tegra.o] Error 1
so somebody needs to pick up this patch:
diff --git a/drivers/ata/ahci_tegra.c b/drivers/ata/ahci_tegra.c
index d30bb21afd67..d7c6b1f550cd 100644
--- a/drivers/ata/ahci_tegra.c
+++ b/drivers/ata/ahci_tegra.c
@@ -24,8 +24,8 @@
#include <linux/module.h>
#include <linux/of_device.h>
#include <linux/platform_device.h>
-#include <linux/tegra-powergate.h>
#include <linux/regulator/consumer.h>
+#include <soc/tegra/pmc.h>
#include "ahci.h"
#define SATA_CONFIGURATION_0 0x180
I haven't checked which trees are affected of if you have already posted
a patch to do this.
Arnd
^ permalink raw reply related
* [PATCHv2 12/17] cpuidle: mvebu: make the cpuidle driver capable of handling multiple SoCs
From: Arnd Bergmann @ 2014-07-21 12:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721133534.3415e425@free-electrons.com>
On Monday 21 July 2014 13:35:34 Thomas Petazzoni wrote:
> On Mon, 21 Jul 2014 13:30:47 +0200, Arnd Bergmann wrote:
>
> > > > It would be best to have a way to read a property (or multiple
> > > > properties) from DT instead, to identify the requirements of the
> > > > device individually. However, I guess that would also require
> > > > changing the DT representation in an incompatible way, which we
> > > > normally don't.
> > >
> > > cpuidle is not represented in DT, so besides checking the global
> > > compatible string with of_machine_is_compatible(), or passing data
> > > through platform_data (as proposed in the patch series), I don't really
> > > see how the cpuidle driver could find out which SoC variant is being
> > > used.
> >
> > One way I think it can be done is by looking up the pmsu node
> > and then looking at some of the properties in there.
>
> Which properties do you have in mind? Should we simply use different
> compatible strings for the PMSU node, per SoC ? Some other suggestions ?
I don't know, it really depends on what the differences are between
the SoCs, and I haven't looked at them.
Using the compatible strings would make it work best if you have one
driver per variant, and then share some common code, as opposed to
having one shared driver with a number of exceptions.
If the differences are just a few parameters, it might be better
to encode those parameters in DT properties instead.
Arnd
^ permalink raw reply
* [PATCHv2 12/17] cpuidle: mvebu: make the cpuidle driver capable of handling multiple SoCs
From: Thomas Petazzoni @ 2014-07-21 11:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52019695.n2AjkGEsJ7@wuerfel>
Dear Arnd Bergmann,
On Mon, 21 Jul 2014 13:30:47 +0200, Arnd Bergmann wrote:
> > > It would be best to have a way to read a property (or multiple
> > > properties) from DT instead, to identify the requirements of the
> > > device individually. However, I guess that would also require
> > > changing the DT representation in an incompatible way, which we
> > > normally don't.
> >
> > cpuidle is not represented in DT, so besides checking the global
> > compatible string with of_machine_is_compatible(), or passing data
> > through platform_data (as proposed in the patch series), I don't really
> > see how the cpuidle driver could find out which SoC variant is being
> > used.
>
> One way I think it can be done is by looking up the pmsu node
> and then looking at some of the properties in there.
Which properties do you have in mind? Should we simply use different
compatible strings for the PMSU node, per SoC ? Some other suggestions ?
Thanks,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [PATCHv2 12/17] cpuidle: mvebu: make the cpuidle driver capable of handling multiple SoCs
From: Arnd Bergmann @ 2014-07-21 11:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721131939.20e81354@free-electrons.com>
On Monday 21 July 2014 13:19:39 Thomas Petazzoni wrote:
> On Mon, 21 Jul 2014 13:16:22 +0200, Arnd Bergmann wrote:
>
> > > It isn't possible to do:
> > >
> > > if (of_machine_is_compatible("marvell,armada-370-xp-pmsu"))
> > > cpuidle_register(&armadaxp_cpuidle_driver, NULL);
> > >
> > > ?
> > >
> > > That will prevent the creation of the new single-declaration header file.
> >
> > It would be best to have a way to read a property (or multiple
> > properties) from DT instead, to identify the requirements of the
> > device individually. However, I guess that would also require
> > changing the DT representation in an incompatible way, which we
> > normally don't.
>
> cpuidle is not represented in DT, so besides checking the global
> compatible string with of_machine_is_compatible(), or passing data
> through platform_data (as proposed in the patch series), I don't really
> see how the cpuidle driver could find out which SoC variant is being
> used.
One way I think it can be done is by looking up the pmsu node
and then looking at some of the properties in there.
Arnd
^ permalink raw reply
* [RFC PATCH 4/7] ARM: OMAP4+: PRM: register interrupt information from DT
From: Tony Lindgren @ 2014-07-21 11:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAGo_u6q2NOxWVG3LOfAyk8qLZss5N6MxCvYkf-yN8c4ec4mftw@mail.gmail.com>
* Nishanth Menon <nm@ti.com> [140721 04:24]:
> On Mon, Jul 21, 2014 at 5:51 AM, Tony Lindgren <tony@atomide.com> wrote:
> >
> >> +static struct of_device_id omap_prm_dt_match_table[] = {
> >> + { .compatible = "ti,omap4-prm" },
> >> + { .compatible = "ti,omap5-prm" },
> >> + { .compatible = "ti,dra7-prm" },
> >> + { }
> >> +};
> >> +
> >
> > I'd like to avoid adding more driver like stuff to mach-omap2
> > and parsing compatible flags and dealing with interupts sounds
> > very driver like.. But maybe just the handling can be moved
> > out?
>
> I understand your view, but, Handling of interrupts is already in
> place even now in mach-omap2. Currently the prm devices are handled by
> mach-omap2 and all this does it to prevent hardcoding of irq numbers
> within the current code.
Yeah but at a cost of no dev entry, no probe etc. I'd rather keep
that SoC specific data around until a driver can deal with it
in a standard way.
> > Would a simple driver be doable that parses the compatible
> > flags, takes care of the IRQ chaining, and gets some SoC specific
> > function pointers as auxdata?
>
> Tero has been trying to move PRM/CM stuff to a separate drivers of
> thier own. With that there wont be a need for auxdata even. - this
> current logic will get merged with that driver - if and when that is
> ready. I am not actually adding any driver logic here - just reusing
> the logic and providing glue for using dt description instead of
> hardcoded logic that the current mach-omap2 driver does.
Well how about let's just leave out the non-standard parts for
now, then once the PRM/CM driver can deal with, it can do things
in a normal way?
Regards,
Tony
^ permalink raw reply
* [RFC PATCH 4/7] ARM: OMAP4+: PRM: register interrupt information from DT
From: Nishanth Menon @ 2014-07-21 11:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721105149.GU18374@atomide.com>
On Mon, Jul 21, 2014 at 5:51 AM, Tony Lindgren <tony@atomide.com> wrote:
>
>> +static struct of_device_id omap_prm_dt_match_table[] = {
>> + { .compatible = "ti,omap4-prm" },
>> + { .compatible = "ti,omap5-prm" },
>> + { .compatible = "ti,dra7-prm" },
>> + { }
>> +};
>> +
>
> I'd like to avoid adding more driver like stuff to mach-omap2
> and parsing compatible flags and dealing with interupts sounds
> very driver like.. But maybe just the handling can be moved
> out?
I understand your view, but, Handling of interrupts is already in
place even now in mach-omap2. Currently the prm devices are handled by
mach-omap2 and all this does it to prevent hardcoding of irq numbers
within the current code.
>
> Would a simple driver be doable that parses the compatible
> flags, takes care of the IRQ chaining, and gets some SoC specific
> function pointers as auxdata?
Tero has been trying to move PRM/CM stuff to a separate drivers of
thier own. With that there wont be a need for auxdata even. - this
current logic will get merged with that driver - if and when that is
ready. I am not actually adding any driver logic here - just reusing
the logic and providing glue for using dt description instead of
hardcoded logic that the current mach-omap2 driver does.
>
> That would allow further work later on to remove the auxdata
> dependencies possibly.
--
---
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCHv2 12/17] cpuidle: mvebu: make the cpuidle driver capable of handling multiple SoCs
From: Thomas Petazzoni @ 2014-07-21 11:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8387001.GKG5goCh1a@wuerfel>
Dear Arnd Bergmann,
On Mon, 21 Jul 2014 13:16:22 +0200, Arnd Bergmann wrote:
> > It isn't possible to do:
> >
> > if (of_machine_is_compatible("marvell,armada-370-xp-pmsu"))
> > cpuidle_register(&armadaxp_cpuidle_driver, NULL);
> >
> > ?
> >
> > That will prevent the creation of the new single-declaration header file.
>
> It would be best to have a way to read a property (or multiple
> properties) from DT instead, to identify the requirements of the
> device individually. However, I guess that would also require
> changing the DT representation in an incompatible way, which we
> normally don't.
cpuidle is not represented in DT, so besides checking the global
compatible string with of_machine_is_compatible(), or passing data
through platform_data (as proposed in the patch series), I don't really
see how the cpuidle driver could find out which SoC variant is being
used.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply
* [RFC PATCH 3/7] ARM: OMAP4+: PRM: remove "wkup" event
From: Nishanth Menon @ 2014-07-21 11:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140721104413.GT18374@atomide.com>
On Mon, Jul 21, 2014 at 5:44 AM, Tony Lindgren <tony@atomide.com> wrote:
>
> Hmm so why was it added originally then?
>
> Do the PRM_IRQSTATUS line and the following line belong together
> or is it missing something?
Seems like to have been a copy paste from OMAP3 code which did have
wakeup event at bit 0.
--
---
Regards,
Nishanth Menon
^ 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