* [PATCH v7 19/22] ARM: OMAP3: clock data: get rid of unused USB host clock aliases and dummies
From: Felipe Balbi @ 2013-01-17 21:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1301171854280.14118@utopia.booyaka.com>
Hi,
On Thu, Jan 17, 2013 at 07:00:00PM +0000, Paul Walmsley wrote:
> Hi Roger,
>
> On Thu, 17 Jan 2013, Tony Lindgren wrote:
>
> > * Roger Quadros <rogerq@ti.com> [130117 03:34]:
> > > We don't need multiple aliases for the OMAP USB host clocks and neither
> > > the dummy clocks so remove them.
> >
> > It's best that Paul queues this and the next patch as these clock alias
> > clean-up patches can be done separately. That way the dependency between
> > arch/arm/*omap* code is cut away as these files should be moved to live
> > under drivers/clk/omap.
>
> Per Tony's request, I'll queue these two cleanup patches for 3.10 -- or
> whatever Linus will call it.
do you mean v3.9 ?
--
balbi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130117/6f1fd568/attachment.sig>
^ permalink raw reply
* [PATCH 2/2] ARM: DT: tegra: Add Toradex Iris carrier board with T20 512MB COM
From: Stephen Warren @ 2013-01-17 20:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358423961-24318-2-git-send-email-dev@lynxeye.de>
On 01/17/2013 04:59 AM, Lucas Stach wrote:
> This adds the device tree for the Toradex Iris carrier board used
> together with a Colibri T20 512MB COM.
> diff --git a/arch/arm/boot/dts/tegra20-iris-512.dts b/arch/arm/boot/dts/tegra20-iris-512.dts
> + board_regulators {
Similarly, name that node just regulators
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <0>;
Those properties will then already exist, so no need to duplicate them here.
> + usb_host_vbus {
That would be regulator at 3
> + compatible = "regulator-fixed";
> + reg = <0>;
That reg = <3>;
(or start numbering the board entries at say 100 to leave room for
changes in the COM include file)
> + regulator-name = "usb_host_vbus";
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + regulator-boot-on;
> + regulator-always-on;
> + gpio = <&gpio 178 0>;
> + };
> +
> + vcc_sd_reg: regulator at 3 {
> + compatible = "regulator-fixed";
> + reg = <1>;
And the node name and reg property here would be 4.
> + regulator-name = "vcc_sd";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + };
> + };
> +};
Oh and in patch 1, I noticed spaces after < or before >; could you
remove those while you're at it. Thanks.
^ permalink raw reply
* [PATCH 1/2] ARM: DT: tegra: Add Colibri T20 512MB COM
From: Stephen Warren @ 2013-01-17 20:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358423961-24318-1-git-send-email-dev@lynxeye.de>
On 01/17/2013 04:59 AM, Lucas Stach wrote:
> This adds the device tree include file for the Toradex Colibri T20
> Computer on Module (COM). It's only valid for the 512MB RAM version of
> the module, as the 256MB version needs different EMC tables and flash
> configuration. To make this clear the suffix -512 was added to the board
> compatible string.
>
> The Colibri T20 uses a Tegra2 SoC and has onboard USB Ethernet and AC97
> sound.
>
> Still some things like onboard NAND support missing, but should be a
> good base for further development.
> diff --git a/arch/arm/boot/dts/tegra20-colibri-512.dtsi b/arch/arm/boot/dts/tegra20-colibri-512.dtsi
> + temperature-sensor at 4c {
> + compatible = "national,lm95245";
You should probably add that compatible value to
Documentation/devicetree/bindings/i2c/trivial-devices.txt.
> + i2c at 7000c000 {
> + clock-frequency = <400000>;
> + };
> +
> + i2c_ddc: i2c at 7000c400 {
> + clock-frequency = <100000>;
> + };
> +
> + i2c at 7000c500 {
> + clock-frequency = <400000>;
> + };
> + serial at 70006000 {
> + clock-frequency = <216000000>;
> + };
> +
> + serial at 70006300 {
> + clock-frequency = <216000000>;
> + };
> +
> + usb at c5000000 {
> + dr_mode = "otg";
> + };
> +
> + usb at c5004000 {
> + status = "okay";
> + nvidia,phy-reset-gpio = <&gpio 169 0>; /* gpio PV1 */
> + };
> +
> + sdhci at c8000600 {
> + cd-gpios = <&gpio 23 0>; /* gpio PC7 */
> + vmmc-supply = <&ldo5_reg>;
> + vqmmc-supply = <&vcc_sd_reg>;
> + };
I assume that all of those nodes are meant to have status="okay"?
Oh, I see those are in the top-level board .dts file. You may as well
put all the properties there; stuff like the GPIOs and regulators at
least would be purely specific to the individual board, and not the COM.
I guess we should really move the serial node's clock-frequency property
in the SoC .dtsi files.
> + com_regulators {
I think just call that "regulators"; the final board .dts file can
easily add more sub-nodes to this node, so there's no need to try and
avoid any naming conflict here. See Cardhu as an example.
> + vdd_5v0_reg: com_reg0 {
Those should be named regulator at 0, regulator at 1, etc.
^ permalink raw reply
* [PATCH 10/14] PCI: tegra: Move PCIe driver to drivers/pci/host
From: Thierry Reding @ 2013-01-17 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130117162218.GA29016@arm.com>
On Thu, Jan 17, 2013 at 04:22:18PM +0000, Andrew Murray wrote:
> On Thu, Jan 17, 2013 at 04:05:02PM +0000, Thierry Reding wrote:
> > On Thu, Jan 17, 2013 at 03:42:36PM +0000, Andrew Murray wrote:
> > > On Wed, Jan 16, 2013 at 06:31:01PM +0000, Thierry Reding wrote:
> > > > Alright, putting the functions into pci_ops doesn't sound like a very
> > > > good idea then. Or perhaps it would make sense for hardware where the
> > > > root complex and the MSI controller are handled by the same driver.
> > > > Basically it could be done as a shortcut and if those are not filled
> > > > in, the drivers could still opt to look up an MSI controller from a
> > > > phandle specified in DT.
> > > >
> > > > Even another alternative would be to keep the functions within the
> > > > struct pci_ops and use generic ones if an external MSI controller is
> > > > used. Just tossing around ideas.
> > >
> > > I think an ideal solution would be for additional logic in drivers/msi.c
> > > (e.g. in functions like msi_capability_init) to determine (based on the
> > > passed in pci_dev) which MSI controller ops to use. I'm not sure the best
> > > way to implement an association between an MSI controller and PCI busses
> > > (I believe arch/sparc does something like this - perhaps there will be
> > > inspiration there).
> > >
> > > As you've pointed out, most RCs will have their own MSI controllers - so
> > > it should be easy to register and associate both together.
> > >
> > > I've submitted my previous work on MSI controller registration, but it
> > > doesn't quite solve this problem - perhaps it can be a starting point?
> >
> > We basically have two cases:
> >
> > - The PCI host bridge contains registers for MSI support. In that case
> > it makes little sense to uncouple the MSI implementation from the
> > host bridge driver.
> >
> > - An MSI controller exists outside of the PCI host bridge. The PCI
> > host bridge would in that case have to lookup an MSI controller (via
> > DT phandle or some other method).
> >
> > In either of those cases, does it make sense to use the MSI support
> > outside the scope of the PCI infrastructure? That is, would devices
> > other than PCI devices be able to generate an MSI?
>
> I've come around to your way of thinking. Your approach sounds good for
> registration of MSI ops - let the RC host driver do it (it probably has its
> own), or use a helper for following a phandle to get ops that are not part
> of the driver. MSIs won't be used outside of PCI devices.
>
> Though existing drivers will use MSI framework functions to request MSIs, that
> will result in callbacks to the arch_setup_msi_irqs type functions. These
> functions would need to be updated to find these new ops if they exist, i.e. by
> traversing the pci_dev structure up to the RC and finding a suitable structure.
>
> Perhaps the msi ops could live alongside pci_ops in the pci_bus structure. This
> way when traversing up the buses from the provided pci_dev - the first bus with
> msi ops populated would be used?
>
> If no ops are found, the standard arch callbacks can be called - thus preserving
> exiting functionality.
Yes, what you describe is exactly what I had in mind. I've been thinking
about a possible implementation and there may be some details that could
prove difficult to resolve. For instance, we likely need to pass context
around for the MSI ops, or else make sure that they can find the context
from the struct pci_dev or by traversing upwards from it.
I think for the case where the MSI hardware is controlled by the same
driver as the PCI host bridge, doing this is easy because the context
could be part of the PCI host bridge context, which in case of Tegra is
stored in struct pci_bus' sysdata field (which is actually an ARM struct
pci_sys_data and in turn stores a pointer to the struct tegra_pcie in
the .private_data field). Other drivers often just use a global variable
assuming that there will only ever be a single instance of the PCI host
bridge.
If the MSI controller is external to the PCI host bridge, things get a
little more complicated. The easiest way would probably be to store the
context along with the PCI host bridge context and use simple wrappers
around the actual implementations to retrieve the PHB context and pass
the attached MSI context.
Maybe this could even be made more generic by adding a struct msi_ops *
along with a struct msi_chip * in struct pci_bus. Perhaps I should try
and code something up to make things more concrete.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130117/e0bd9143/attachment-0001.sig>
^ permalink raw reply
* [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
From: Arnd Bergmann @ 2013-01-17 20:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F800EB.6040104@web.de>
On Thursday 17 January 2013, Soeren Moch wrote:
> On 17.01.2013 11:49, Arnd Bergmann wrote:
> > On Wednesday 16 January 2013, Soeren Moch wrote:
> >>>> I will see what I can do here. Is there an easy way to track the buffer
> >>>> usage without having to wait for complete exhaustion?
> >>>
> >>> DMA_API_DEBUG
> >>
> >> OK, maybe I can try this.
> >>>
> >
> > Any success with this? It should at least tell you if there is a
> > memory leak in one of the drivers.
>
> Not yet, sorry. I have to do all the tests in my limited spare time.
> Can you tell me what to search for in the debug output?
Actually now that I've looked closer, you can't immediately see
all the mappings as I thought.
But please try enabling DMA_API_DEBUG in combination with this
one-line patch:
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 6b2fb87..3df74ac 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -497,6 +497,7 @@ static void *__alloc_from_pool(size_t size, struct page **ret_page)
pr_err_once("ERROR: %u KiB atomic DMA coherent pool is too small!\n"
"Please increase it with coherent_pool= kernel parameter!\n",
(unsigned)pool->size / 1024);
+ debug_dma_dump_mappings(NULL);
}
spin_unlock_irqrestore(&pool->lock, flags);
That will show every single allocation that is currently active. This lets
you see where all the memory went, and if there is a possible leak or
excessive fragmentation.
Arnd
^ permalink raw reply related
* Atmel USBA UDC support (USB gadget)
From: Dimitrios Siganos @ 2013-01-17 19:46 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
I am looking for some pointers regarding Atmel USBA UDC (USB
gadget driver at91_udc).
We are using an AT91SAM9g25 and we want to use it as a USB gadget
device. We are using linux kernel 3.7 (official linux with some of our
own patches).
I'd like to get at91_udc working on my system but it seems that I am
missing device tree configuration and possible platform code. What I'd
really like to know is if this has been done before and, if yes, where?
Regards,
Dimitrios Siganos
^ permalink raw reply
* [PATCH v2 2/3] at91: 9x5: add DT parameters to enable PMECC
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-01-17 19:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358393072-14794-3-git-send-email-josh.wu@atmel.com>
On 11:24 Thu 17 Jan , Josh Wu wrote:
> Default ecc correctable setting is 2bits in 512 bytes.
full name sam the soc
>
> Signed-off-by: Josh Wu <josh.wu@atmel.com>
> ---
> change log:
> v2: rebase to v3.8-rc3
>
> arch/arm/boot/dts/at91sam9x5.dtsi | 4 ++++
> arch/arm/boot/dts/at91sam9x5cm.dtsi | 5 ++++-
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/at91sam9x5.dtsi b/arch/arm/boot/dts/at91sam9x5.dtsi
> index 40ac3a4..eedc191 100644
> --- a/arch/arm/boot/dts/at91sam9x5.dtsi
> +++ b/arch/arm/boot/dts/at91sam9x5.dtsi
> @@ -480,7 +480,11 @@
> #address-cells = <1>;
> #size-cells = <1>;
> reg = <0x40000000 0x10000000
> + 0xffffe000 0x600 /* PMECC Registers */
> + 0xffffe600 0x200 /* PMECC Error Location Registers */
> + 0x00100000 0x100000 /* ROM code */
I do not like this at all we request 1M of memory where we jsut need a few for
the tables
Best Regards,
J.
> >;
> + atmel,pmecc-lookup-table-offset = <0x8000 0x10000>;
> atmel,nand-addr-offset = <21>;
> atmel,nand-cmd-offset = <22>;
> pinctrl-names = "default";
> diff --git a/arch/arm/boot/dts/at91sam9x5cm.dtsi b/arch/arm/boot/dts/at91sam9x5cm.dtsi
> index 31e7be2..4027ac7 100644
> --- a/arch/arm/boot/dts/at91sam9x5cm.dtsi
> +++ b/arch/arm/boot/dts/at91sam9x5cm.dtsi
> @@ -26,7 +26,10 @@
> ahb {
> nand0: nand at 40000000 {
> nand-bus-width = <8>;
> - nand-ecc-mode = "soft";
> + nand-ecc-mode = "hw";
> + atmel,has-pmecc; /* Enable PMECC */
> + atmel,pmecc-cap = <2>;
> + atmel,pmecc-sector-size = <512>;
> nand-on-flash-bbt;
> status = "okay";
>
> --
> 1.7.9.5
>
^ permalink raw reply
* [PATCH 4/4 v3] net/smsc911x: Provide common clock functionality
From: David Miller @ 2013-01-17 19:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130117104744.GP20091@gmail.com>
From: Lee Jones <lee.jones@linaro.org>
Date: Thu, 17 Jan 2013 10:47:44 +0000
> https://patchwork.kernel.org/patch/1926971/
I'm fine with this:
Acked-by: David S. Miller <davem@davemloft.net>
^ permalink raw reply
* [PATCH v2 3/3] at91: at91sam9n12: add DT parameters to enable PMECC
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-01-17 19:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358393072-14794-4-git-send-email-josh.wu@atmel.com>
On 11:24 Thu 17 Jan , Josh Wu wrote:
> Default ecc correctable setting is 2bits in 512 bytes.
>
> Signed-off-by: Josh Wu <josh.wu@atmel.com>
this must go via at91 tree
so we can manage other mergie issue on dts
Best Regards,
J.
> ---
> change log:
> v2: rebase to v3.8-rc3
>
> arch/arm/boot/dts/at91sam9n12.dtsi | 1 +
> arch/arm/boot/dts/at91sam9n12ek.dts | 5 ++++-
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/at91sam9n12.dtsi b/arch/arm/boot/dts/at91sam9n12.dtsi
> index e9efb34..eb9f12e 100644
> --- a/arch/arm/boot/dts/at91sam9n12.dtsi
> +++ b/arch/arm/boot/dts/at91sam9n12.dtsi
> @@ -366,6 +366,7 @@
> 0xffffe600 0x00000200
> 0x00100000 0x00100000
> >;
> + atmel,pmecc-lookup-table-offset = <0x8000 0x10000>;
> atmel,nand-addr-offset = <21>;
> atmel,nand-cmd-offset = <22>;
> pinctrl-names = "default";
> diff --git a/arch/arm/boot/dts/at91sam9n12ek.dts b/arch/arm/boot/dts/at91sam9n12ek.dts
> index 0376bf4..d400f8d 100644
> --- a/arch/arm/boot/dts/at91sam9n12ek.dts
> +++ b/arch/arm/boot/dts/at91sam9n12ek.dts
> @@ -71,7 +71,10 @@
>
> nand0: nand at 40000000 {
> nand-bus-width = <8>;
> - nand-ecc-mode = "soft";
> + nand-ecc-mode = "hw";
> + atmel,has-pmecc;
> + atmel,pmecc-cap = <2>;
> + atmel,pmecc-sector-size = <512>;
> nand-on-flash-bbt;
> status = "okay";
> };
> --
> 1.7.9.5
>
^ permalink raw reply
* [PATCH] ARM: OMAP2: Fix missing omap2xxx_clkt_vps_xxx function calls
From: Jon Hunter @ 2013-01-17 19:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1301171848490.14118@utopia.booyaka.com>
Hi Paul,
On 01/17/2013 12:51 PM, Paul Walmsley wrote:
> Hi Jon
>
> On Thu, 10 Jan 2013, Jon Hunter wrote:
>
>> During the migration to the common clock framework, calls to the
>> functions omap2xxx_clkt_vps_late_init() and
>> omap2xxx_clkt_vps_check_bootloader_rates() were not preserved for
>> OMAP2420 and OMAP2430. This causes the variables "sys_ck_rate" and
>> "curr_prcm_set" to be uninitialised on boot. On reboot, this causes the
>> following error message to be displayed because the appropriate MPU
>> clock frequency (derived from sys_ck_rate) cannot be found.
>>
>> "Could not set MPU rate to 4294MHz"
>
> I don't see this message on 2430sdp or n800 with v3.8-rc3, but maybe
> that's due to sys_clk differences. Do you still see this on v3.8-rc3
> with H4?
Yes I still see it. You don't see it on reboot?
The reason why there is such a large number is because
omap2_round_to_table_rate() is returning the value -EINVAL. You could
add a print to omap2_round_to_table_rate() to see what it returns on
reboot. Or we could add a WARN to the function is sys_ck_rate is 0 for
testing.
> Also, there's already a call to omap2xxx_clkt_vps_check_bootloader_rates()
> -- is it necessary to add another one?
Thanks. I see that now and so that is not needed then.
Cheers
Jon
^ permalink raw reply
* [PATCH 0/4] gpio: introduce descriptor-based interface
From: Arnd Bergmann @ 2013-01-17 19:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301170850.43655.sfking@fdwdc.com>
On Thursday 17 January 2013, Steven King wrote:
> I haven't been keeping up with the kernel list of late, can someone point me
> to what''s being discussed so I can see what were talking about here?
We are discussion about changes to the GPIO API, in particular about
adding a descriptor (i.e. pointer to struct) based interface to
replace integers as the primary key.
Any kind of change on this level is currently problematic because it
is basically impossible to tell which files are implementing the
current interface and would need to get changed along with changing
gpiolib. If everything goes through gpiolib, it's much easier
to make compatible extensions in one place.
Do you have any numbers about how much of a difference for your
platforms we are talking about at most?
Arnd
^ permalink raw reply
* [PATCH] ARM: OMAP AM3517/05: hwmod data: block WFI when EMAC active
From: Paul Walmsley @ 2013-01-17 19:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130108204347.GC1876@animalcreek.com>
Hi Mark
On Tue, 8 Jan 2013, Mark A. Greer wrote:
> Sorry to nag but I think the comment needs to be updated to remove the
> sentence about the missing EMAC hwmod.
You are absolutely right, and the correction is very much appreciated.
Updated patch follows.
- Paul
From: Paul Walmsley <paul@pwsan.com>
Date: Sun, 30 Dec 2012 10:36:36 -0700
Subject: [PATCH] ARM: OMAP AM3517/05: hwmod data: block WFI when EMAC active
According to Mark Greer, on OMAP AM3517/3505 chips, the EMAC is unable
to wake the ARM up from WFI:
http://www.spinics.net/lists/arm-kernel/msg174734.html
Further troubleshooting was unable to narrow the problem down. So we
don't have much choice other than to block WFI when the EMAC is active
with the HWMOD_BLOCK_WFI flag.
Based on Mark's original patch. We're removing the omap_device-based
pm_lats code, so a different approach was needed.
This third version contains some corrections thanks to Mark's review.
Signed-off-by: Paul Walmsley <paul@pwsan.com>
Cc: Mark A. Greer <mgreer@animalcreek.com>
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 8bb2628..ac7e03e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3493,7 +3493,12 @@ static struct omap_hwmod am35xx_emac_hwmod = {
.name = "davinci_emac",
.mpu_irqs = am35xx_emac_mpu_irqs,
.class = &am35xx_emac_class,
- .flags = HWMOD_NO_IDLEST,
+ /*
+ * According to Mark Greer, the MPU will not return from WFI
+ * when the EMAC signals an interrupt.
+ * http://www.spinics.net/lists/arm-kernel/msg174734.html
+ */
+ .flags = (HWMOD_NO_IDLEST | HWMOD_BLOCK_WFI),
};
/* l3_core -> davinci emac interface */
--
1.7.10.4
^ permalink raw reply related
* [PATCH 00/15] OMAP SHAM & AES Crypto Updates
From: Paul Walmsley @ 2013-01-17 19:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130108203853.GB1876@animalcreek.com>
Hi Mark,
I regret the delay,
On Tue, 8 Jan 2013, Mark A. Greer wrote:
> On Sun, Dec 23, 2012 at 08:40:43AM +0000, Paul Walmsley wrote:
>
> > - The patch series causes AM3517/3505 to crash. I'd guess this is due to
> > the SHAM/AES modules being initialized on those chips, but they probably
> > don't exist there. Can you change the initialization for those on OMAP3
> > to only take place on OMAP34xx/36xx GP? I guess you'd need to create new
> > lists for those in the hwmod init.
>
> All am35xx GPs have the SHAM and AES modules except some very old ones.
> I've been told that there should be very few of the "old" ones around
> (I don't know how to differentiate them). We're likely safe since the
> SHAM & AES modules are not enabled in omap2plus_defconfig so nobody
> should be enabling them on an am35xx unless they know that they have
> the modules. Do you agree?
Those will presumably only enable or disable the device drivers. The
hwmod code will probably still try to write to those IP blocks if they are
listed as present in the hwmod data, during the initial reset-and-idle
phase.
What do you think about adding an am35xx_es11plus_hwmod_ocp_ifs[] array to
omap_hwmod_3xxx_data.c for these secure hwmods? That carries the implicit
and possibly wrong assumption that it's likely to be ES1.0 devices that
are missing the SHAM/AES, but it seems unlikely that TI would have
multiple silicon revs running around claiming to be ES1.1? Or maybe I'm
just being na?ve.
> The issue that you're likely running into is that 'CK_AM35XX' needs to be
> added for aes2_ick & sha12_ick in cclock3xxx_data.c. The following
> patch should fix it (applies to my submitted/crypto/hwmod branch):
>
> diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c b/arch/arm/mach-omap2/cclock3xxx_data.c
> index 582b055..aa5bdf6 100644
> --- a/arch/arm/mach-omap2/cclock3xxx_data.c
> +++ b/arch/arm/mach-omap2/cclock3xxx_data.c
> @@ -3332,10 +3332,10 @@ static struct omap_clk omap3xxx_clks[] = {
> CLK("omap_hsmmc.2", "ick", &mmchs3_ick, CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
> CLK(NULL, "mmchs3_ick", &mmchs3_ick, CK_3430ES2PLUS | CK_AM35XX | CK_36XX),
> CLK(NULL, "icr_ick", &icr_ick, CK_34XX | CK_36XX),
> - CLK("omap-aes", "ick", &aes2_ick, CK_34XX | CK_36XX),
> - CLK(NULL, "aes2_ick", &aes2_ick, CK_34XX | CK_36XX),
> - CLK("omap-sham", "ick", &sha12_ick, CK_34XX | CK_36XX),
> - CLK(NULL, "sha12_ick", &sha12_ick, CK_34XX | CK_36XX),
> + CLK("omap-aes", "ick", &aes2_ick, CK_34XX | CK_AM35XX | CK_36XX),
> + CLK(NULL, "aes2_ick", &aes2_ick, CK_34XX | CK_AM35XX | CK_36XX),
> + CLK("omap-sham", "ick", &sha12_ick, CK_34XX | CK_AM35XX | CK_36XX),
> + CLK(NULL, "sha12_ick", &sha12_ick, CK_34XX | CK_AM35XX | CK_36XX),
> CLK(NULL, "des2_ick", &des2_ick, CK_34XX | CK_36XX),
> CLK("omap_hsmmc.1", "ick", &mmchs2_ick, CK_3XXX),
> CLK("omap_hsmmc.0", "ick", &mmchs1_ick, CK_3XXX),
>
>
> Please let me know if this patch works for you and, if it does, I'll respin
> my patches to add those changes.
If those clocks are referenced by the hwmods, that that patch makes sense
to me. Haven't had the chance to test it yet but maybe tomorrow. On the
other hand it looks 'obviously correct' so maybe just add that change to
your patches and repost that one?
- Paul
^ permalink raw reply
* [RFC v2 13/18] ARM: OMAP2+: AM33XX: timer: Interchance clkevt and clksrc timers
From: Jon Hunter @ 2013-01-17 19:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1356959231-17335-14-git-send-email-vaibhav.bedia@ti.com>
On 12/31/2012 07:07 AM, Vaibhav Bedia wrote:
> AM33XX has two timers (DTIMER0/1) in the WKUP domain.
> On GP devices the source of DMTIMER0 is fixed to an
> inaccurate internal 32k RC oscillator and this makes
> the DMTIMER0 practically either as a clocksource or
> as clockevent.
>
> Currently the timer instance in WKUP domain is used
> as the clockevent and the timer in non-WKUP domain
> as the clocksource. DMTIMER1 in WKUP domain can keep
> running in suspend from a 32K clock fed from external
> OSC and can serve as the persistent clock for the kernel.
> To enable this, interchange the timers used as clocksource
> and clockevent for AM33XX.
>
> For now a new DT property has been added to allow the timer code
> to select the timer with the right property.
>
> It has been pointed out by Santosh Shilimkar and Kevin Hilman
> that such a change will result in soc-idle never being achieved
> on AM33XX. There are other reasons why soc-idle does not look
> feasible on AM33XX so for now we go ahead with the interchange
> of the the timers. If at a later point of time we do come up
> with an approach which makes soc-idle possible on AM33XX, this
> can be revisited.
>
> Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
> Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> Cc: Tony Lingren <tony@atomide.com>
> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Benoit Cousson <b-cousson@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> Cc: Kevin Hilman <khilman@deeprootsystems.com>
> Cc: Jon Hunter <jon-hunter@ti.com>
>
> ---
> v1->v2:
> Use DT properties for changing the timers
>
> .../devicetree/bindings/arm/omap/timer.txt | 2 ++
> arch/arm/boot/dts/am33xx.dtsi | 1 +
> arch/arm/mach-omap2/timer.c | 6 +++---
> 3 files changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/omap/timer.txt b/Documentation/devicetree/bindings/arm/omap/timer.txt
> index 8732d4d..62d4f2c 100644
> --- a/Documentation/devicetree/bindings/arm/omap/timer.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/timer.txt
> @@ -18,6 +18,8 @@ Optional properties:
> - ti,timer-pwm: Indicates the timer can generate a PWM output.
> - ti,timer-secure: Indicates the timer is reserved on a secure OMAP device
> and therefore cannot be used by the kernel.
> +- ti,timer-non-wkup Indicates the timer is in non-wkup power domain and hence
> + will lose register context when the power domain transitions
I was hoping that we could avoid adding another property, especially
given that his equivalent to a timer that does not have the
"ti,timer-alwon" property.
> Example:
>
> diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
> index 4731748..b4e8bf7 100644
> --- a/arch/arm/boot/dts/am33xx.dtsi
> +++ b/arch/arm/boot/dts/am33xx.dtsi
> @@ -251,6 +251,7 @@
> reg = <0x48040000 0x400>;
> interrupts = <68>;
> ti,hwmods = "timer2";
> + ti,timer-non-wkup;
Is this is only one not in the wake-up domain?
> };
>
> timer3: timer at 48042000 {
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index 38f9cbc..cfb3413 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -264,7 +264,7 @@ static int __init omap_dm_timer_init_one(struct omap_dm_timer *timer,
> int r = 0;
>
> if (of_have_populated_dt()) {
> - np = omap_get_timer_dt(omap_timer_match, NULL);
> + np = omap_get_timer_dt(omap_timer_match, property);
> if (!np)
> return -ENODEV;
>
> @@ -633,8 +633,8 @@ OMAP_SYS_TIMER(3_gp, gptimer);
> #endif /* CONFIG_ARCH_OMAP3 */
>
> #ifdef CONFIG_SOC_AM33XX
> -OMAP_SYS_GP_TIMER_INIT(3_am33xx, 1, OMAP4_MPU_SOURCE, "ti,timer-alwon",
> - 2, OMAP4_MPU_SOURCE);
> +OMAP_SYS_GP_TIMER_INIT(3_am33xx, 2, OMAP4_MPU_SOURCE, "ti,timer-non-wkup",
> + 1, OMAP4_MPU_SOURCE);
It seems to me here that we should specify the property "ti,timer-alwon"
for the clocksource and then no property for the clockevent. Hence, may
be the code needs to be adjusted so that if clockevent or clocksource
can use any timer (ie. no property specified), we look for a timer that
has no "ti-timer-xxxx" properties. This will ensure that if we need a
particular timer for clocksource, which we look for after clockevent, it
will be available.
Cheers
Jon
^ permalink raw reply
* [PATCH v7 19/22] ARM: OMAP3: clock data: get rid of unused USB host clock aliases and dummies
From: Paul Walmsley @ 2013-01-17 19:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130117170321.GJ14149@atomide.com>
Hi Roger,
On Thu, 17 Jan 2013, Tony Lindgren wrote:
> * Roger Quadros <rogerq@ti.com> [130117 03:34]:
> > We don't need multiple aliases for the OMAP USB host clocks and neither
> > the dummy clocks so remove them.
>
> It's best that Paul queues this and the next patch as these clock alias
> clean-up patches can be done separately. That way the dependency between
> arch/arm/*omap* code is cut away as these files should be moved to live
> under drivers/clk/omap.
Per Tony's request, I'll queue these two cleanup patches for 3.10 -- or
whatever Linus will call it.
- Paul
^ permalink raw reply
* [PATCH] ARM: OMAP2: Fix missing omap2xxx_clkt_vps_xxx function calls
From: Paul Walmsley @ 2013-01-17 18:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1357851209-5332-1-git-send-email-jon-hunter@ti.com>
Hi Jon
On Thu, 10 Jan 2013, Jon Hunter wrote:
> During the migration to the common clock framework, calls to the
> functions omap2xxx_clkt_vps_late_init() and
> omap2xxx_clkt_vps_check_bootloader_rates() were not preserved for
> OMAP2420 and OMAP2430. This causes the variables "sys_ck_rate" and
> "curr_prcm_set" to be uninitialised on boot. On reboot, this causes the
> following error message to be displayed because the appropriate MPU
> clock frequency (derived from sys_ck_rate) cannot be found.
>
> "Could not set MPU rate to 4294MHz"
I don't see this message on 2430sdp or n800 with v3.8-rc3, but maybe
that's due to sys_clk differences. Do you still see this on v3.8-rc3
with H4?
Also, there's already a call to omap2xxx_clkt_vps_check_bootloader_rates()
-- is it necessary to add another one?
- Paul
^ permalink raw reply
* [RFC v2 12/18] ARM: OMAP2+: timer: Add suspend-resume callbacks for clockevent device
From: Jon Hunter @ 2013-01-17 18:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <B5906170F1614E41A8A28DE3B8D121433ECE0D51@DBDE01.ent.ti.com>
On 01/10/2013 10:37 PM, Bedia, Vaibhav wrote:
> On Tue, Jan 08, 2013 at 20:45:10, Shilimkar, Santosh wrote:
>> On Monday 31 December 2012 06:37 PM, Vaibhav Bedia wrote:
>>> The current OMAP timer code registers two timers -
>>> one as clocksource and one as clockevent.
>>> AM33XX has only one usable timer in the WKUP domain
>>> so one of the timers needs suspend-resume support
>>> to restore the configuration to pre-suspend state.
>>>
>>> commit adc78e6 (timekeeping: Add suspend and resume
>>> of clock event devices) introduced .suspend and .resume
>>> callbacks for clock event devices. Leverages these
>>> callbacks to have AM33XX clockevent timer which is
>>> in not in WKUP domain to behave properly across system
>>> suspend.
>>>
>>> Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
>>> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
>>> Cc: Benoit Cousson <b-cousson@ti.com>
>>> Cc: Paul Walmsley <paul@pwsan.com>
>>> Cc: Kevin Hilman <khilman@deeprootsystems.com>
>>> Cc: Vaibhav Hiremath <hvaibhav@ti.com>
>>> Cc: Jon Hunter <jon-hunter@ti.com>
>>> ---
>>> v1->v2:
>>> Get rid of harcoded timer id.
>>> Note: since a platform device is not created for these timer
>>> instances and because there's very minimal change needed for
>>> restarting the timer a full blown context save and restore
>>> has been skipped.
>>>
>>> arch/arm/mach-omap2/timer.c | 33 +++++++++++++++++++++++++++++++++
>>> 1 files changed, 33 insertions(+), 0 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
>>> index 691aa67..38f9cbc 100644
>>> --- a/arch/arm/mach-omap2/timer.c
>>> +++ b/arch/arm/mach-omap2/timer.c
>>> @@ -128,6 +128,36 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode mode,
>>> }
>>> }
>>>
>>> +static void omap_clkevt_suspend(struct clock_event_device *unused)
>>> +{
>>> + char name[10];
>>> + struct omap_hwmod *oh;
>>> +
>>> + sprintf(name, "timer%d", clkev.id);
>>> + oh = omap_hwmod_lookup(name);
>>> + if (!oh)
>>> + return;
>>> +
>>> + __omap_dm_timer_stop(&clkev, 1, clkev.rate);
>>> + omap_hwmod_idle(oh);
>>> +}
>>> +
>>> +static void omap_clkevt_resume(struct clock_event_device *unused)
>>> +{
>>> + char name[10];
>>> + struct omap_hwmod *oh;
>>> +
>>> + sprintf(name, "timer%d", clkev.id);
>>> + oh = omap_hwmod_lookup(name);
>>> + if (!oh)
>>> + return;
>>> +
>>> + omap_hwmod_enable(oh);
>>> + __omap_dm_timer_load_start(&clkev,
>>> + OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0, 1);
>>> + __omap_dm_timer_int_enable(&clkev, OMAP_TIMER_INT_OVERFLOW);
>>> +}
>>> +
>> Am still bit uncomfortable with direct hwmod usage in the suspend/resmue
>> hooks.
>>
>> Jon, Any alternatives you can think of ?
>>
>
> Jon,
>
> Any suggestions here?
Sorry completed this missed this!
Unfortunately, I don't have any good suggestions here. However, I am
wondering if the suspend/resume handlers can just be calls to
omap_hwmod_idle/enable and we can remove these __omap_dm_timer_xxxx
calls (I don't think they are needed). Furthermore, my understanding is
this is only needed for AM335x (per the changelog), and so we should not
add suspend/resume handlers for all OMAP2+ based devices.
Cheers
Jon
^ permalink raw reply
* OMAP baseline test results for v3.8-rc3
From: Paul Walmsley @ 2013-01-17 18:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F51067.5090008@ti.com>
Hi P?ter,
On Tue, 15 Jan 2013, Peter Ujfalusi wrote:
> On 01/14/2013 06:59 PM, Paul Walmsley wrote:
> > Failing tests: needing investigation
> > ------------------------------------
> >
> > Build tests:
> >
> > * rmk_3430_ldp_allnoconfig, rmk_4430_sdp_allnoconfig: twl4030 build failures
> > - in drivers/mfd/twl-core.c
>
> The following patch fixes these:
> https://lkml.org/lkml/2012/12/24/3
Thanks, I've added that info in the v3.8-rc3 test summary, and moved the
paragraph to the 'resolved by posted patches' section.
- Paul
^ permalink raw reply
* [RFC v2 12/18] ARM: OMAP2+: timer: Add suspend-resume callbacks for clockevent device
From: Jon Hunter @ 2013-01-17 18:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1356959231-17335-13-git-send-email-vaibhav.bedia@ti.com>
On 12/31/2012 07:07 AM, Vaibhav Bedia wrote:
> The current OMAP timer code registers two timers -
> one as clocksource and one as clockevent.
> AM33XX has only one usable timer in the WKUP domain
> so one of the timers needs suspend-resume support
> to restore the configuration to pre-suspend state.
>
> commit adc78e6 (timekeeping: Add suspend and resume
> of clock event devices) introduced .suspend and .resume
> callbacks for clock event devices. Leverages these
> callbacks to have AM33XX clockevent timer which is
> in not in WKUP domain to behave properly across system
> suspend.
>
> Signed-off-by: Vaibhav Bedia <vaibhav.bedia@ti.com>
> Cc: Santosh Shilimkar <santosh.shilimkar@ti.com>
> Cc: Benoit Cousson <b-cousson@ti.com>
> Cc: Paul Walmsley <paul@pwsan.com>
> Cc: Kevin Hilman <khilman@deeprootsystems.com>
> Cc: Vaibhav Hiremath <hvaibhav@ti.com>
> Cc: Jon Hunter <jon-hunter@ti.com>
> ---
> v1->v2:
> Get rid of harcoded timer id.
> Note: since a platform device is not created for these timer
> instances and because there's very minimal change needed for
> restarting the timer a full blown context save and restore
> has been skipped.
>
> arch/arm/mach-omap2/timer.c | 33 +++++++++++++++++++++++++++++++++
> 1 files changed, 33 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
> index 691aa67..38f9cbc 100644
> --- a/arch/arm/mach-omap2/timer.c
> +++ b/arch/arm/mach-omap2/timer.c
> @@ -128,6 +128,36 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode mode,
> }
> }
>
> +static void omap_clkevt_suspend(struct clock_event_device *unused)
> +{
> + char name[10];
> + struct omap_hwmod *oh;
> +
> + sprintf(name, "timer%d", clkev.id);
> + oh = omap_hwmod_lookup(name);
> + if (!oh)
> + return;
> +
> + __omap_dm_timer_stop(&clkev, 1, clkev.rate);
I am not sure you need to call __omap_dm_timer_stop() here. This should
have already been called as timekeeping_suspend() will call
omap2_gp_timer_set_mode() to shutdown the timer.
> + omap_hwmod_idle(oh);
> +}
> +
> +static void omap_clkevt_resume(struct clock_event_device *unused)
> +{
> + char name[10];
> + struct omap_hwmod *oh;
> +
> + sprintf(name, "timer%d", clkev.id);
> + oh = omap_hwmod_lookup(name);
> + if (!oh)
> + return;
> +
> + omap_hwmod_enable(oh);
> + __omap_dm_timer_load_start(&clkev,
> + OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0, 1);
> + __omap_dm_timer_int_enable(&clkev, OMAP_TIMER_INT_OVERFLOW);
Similarly here, I am not sure these __omap_dm_timer_xxxx calls are needed.
> +}
> +
> static struct clock_event_device clockevent_gpt = {
> .name = "gp_timer",
> .features = CLOCK_EVT_FEAT_PERIODIC | CLOCK_EVT_FEAT_ONESHOT,
> @@ -135,6 +165,8 @@ static struct clock_event_device clockevent_gpt = {
> .rating = 300,
> .set_next_event = omap2_gp_timer_set_next_event,
> .set_mode = omap2_gp_timer_set_mode,
> + .suspend = omap_clkevt_suspend,
> + .resume = omap_clkevt_resume,
AFAIK, this is only applicable for AM335x devices and so should not be
added for all.
> };
>
> static struct property device_disabled = {
> @@ -323,6 +355,7 @@ static void __init omap2_gp_clockevent_init(int gptimer_id,
> int res;
>
> clkev.errata = omap_dm_timer_get_errata();
> + clkev.id = gptimer_id;
We should not use gptimer_id anymore. This will go away once the
migration to dev-tree is completed. You may be better off storing the
oh_name in the clock_event_device name field and passing to the
suspend/resume handlers.
Cheers
Jon
^ permalink raw reply
* OMAP baseline test results for v3.8-rc3
From: Paul Walmsley @ 2013-01-17 18:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130114184018.GA18224@blackmetal.musicnaut.iki.fi>
On Mon, 14 Jan 2013, Aaro Koskinen wrote:
> N900 boot is unstable again, I2C issues are back.
>
> Boot succeeds and fails randomly. Let's see if this can be bisected.
> The same kernel works on N950.
Thanks, I've added a section about this to the v3.8-rc3 test summary.
- Paul
^ permalink raw reply
* [[PATCH v2]] OMAP: omap4-panda: add WiLink shared transport power functions
From: Luciano Coelho @ 2013-01-17 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130117173131.GL14149@atomide.com>
Hi Tony,
On Thu, 2013-01-17 at 09:31 -0800, Tony Lindgren wrote:
> * Peter Ujfalusi <peter.ujfalusi@ti.com> [130117 02:44]:
> > On 01/17/2013 11:35 AM, Luciano Coelho wrote:
> > > This out-of-tree code doesn't explain why we need to do the
> > > enable/disable in the board file. We just need to do things a bit
> > > differently in the driver. I'll start cleaning all this stuff up for
> > > -next pretty soon.
> > >
> > > For now, ie. 3.7 (stable) and 3.8, do we agree in taking this patch so
> > > that TI-ST at least works on Panda? Simply reverting the gpio removal
> > > patch doesn't help, because we also need to handle the UART2 muxing
> > > (which my patch does as well).
> >
> > I don't see better way to fix this either. In any case, I give you my:
> >
> > Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
>
> So what is actually broken? The horrible bluetooth muxing over serial
> port? If so, let's rather fix it properly than even attempt to fix
> it as it seems that it's been broken for two merge windows now.
Yes, it is the horrible Bluetooth muxing over serial that is broken. It
has been broken for two merge windows, because nobody seemed to care
until I started looking into it and tried to figure out how to get it to
work. :)
The implementation is really weak and there are loads of things I want
to start fixing/cleaning up. This patch was just my intention to start
with a relatively clean table (ie. horrible or not, at least working).
> Also, let's just do absolutely minimal board-*.c file fixes now.
> This thing should be just moved to use DT so we can flip over omap4
> to be DT only and drop estimated 5k LOC from mach-omap2.
I totally agree, I'll start looking into that next.
But this patch is pretty small and simple, so why not include it to at
least fix the breakage in 3.7 and 3.8? Whether you take it or not now
won't make any difference in the 5k LOC in these kernel versions.
--
Cheers,
Luca.
^ permalink raw reply
* [PATCH 00/16] big.LITTLE low-level CPU and cluster power management
From: Catalin Marinas @ 2013-01-17 17:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.02.1301161614390.6300@xanadu.home>
On Wed, Jan 16, 2013 at 09:18:39PM +0000, Nicolas Pitre wrote:
> On Wed, 16 Jan 2013, Catalin Marinas wrote:
>
> > On Tue, Jan 15, 2013 at 04:44:23PM +0000, Nicolas Pitre wrote:
> > > On Tue, 15 Jan 2013, Joseph Lo wrote:
> > > > So do you have a plan to make it become a generic framework in this
> > > > series or later work?
> > >
> > > It is already generic, except for the name. In other words, you could
> > > start using this code already.
> > >
> > > I'm still debating a good substitute for the bL_ prefix in this series
> > > to give it the appearance of generic code.
> >
> > mc_?
>
> Bah. :-/
Like in multi-cluster (not "Hammer time" ;). But if they are not even
cluster dependent, a simple mp_ would also do.
--
Catalin
^ permalink raw reply
* [PATCH v5 5/9] ARM: davinci: New reset functionality/API provided for Davinci DSP
From: Tivy, Robert @ 2013-01-17 17:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F7E17C.1040607@ti.com>
Thankyou for all your help Sekhar. I'm fine with your fixups (both commentary and code naming).
Regards,
- Rob
> -----Original Message-----
> From: Nori, Sekhar
> Sent: Thursday, January 17, 2013 3:33 AM
> To: Tivy, Robert
> Cc: davinci-linux-open-source at linux.davincidsp.com; linux-arm-
> kernel at lists.infradead.org; Ring, Chris; Grosen, Mark; ohad at wizery.com;
> rob at landley.net; linux-doc at vger.kernel.org
> Subject: Re: [PATCH v5 5/9] ARM: davinci: New reset functionality/API
> provided for Davinci DSP
>
> On 1/11/2013 5:53 AM, Robert Tivy wrote:
> > Since there is no general "reset" support for SoC devices, and since
> the
> > remoteproc driver needs explicit control of the DSP's reset line, a
> new
> > Davinci-specific API is added.
> >
> > This private API will disappear with DT migration. Some discussion
> > regarding a proposed DT "reset" binding is here:
> > https://patchwork.kernel.org/patch/1635051/
> >
> > Modified davinci_clk_init() to set clk "reset" function for clocks
> > that indicate PSC_LRST support. Also fixed indentation issue with
> > function opening curly brace.
> >
> > Signed-off-by: Robert Tivy <rtivy@ti.com>
>
> I applied this patch for v3.9. The subject seemed too long with
> repeated
> references to davinci so I shortened it to:
>
> ARM: davinci: psc: introduce reset API
>
> > --- a/arch/arm/mach-davinci/include/mach/psc.h
> > +++ b/arch/arm/mach-davinci/include/mach/psc.h
> > @@ -246,6 +246,7 @@
> >
> > #define MDSTAT_STATE_MASK 0x3f
> > #define PDSTAT_STATE_MASK 0x1f
> > +#define MDCTL_LRST BIT(8)
> > #define MDCTL_FORCE BIT(31)
> > #define PDCTL_NEXT BIT(0)
> > #define PDCTL_EPCGOOD BIT(8)
> > @@ -253,6 +254,8 @@
> > #ifndef __ASSEMBLER__
> >
> > extern int davinci_psc_is_clk_active(unsigned int ctlr, unsigned int
> id);
> > +extern void davinci_psc_reset_config(unsigned int ctlr, unsigned int
> id,
> > + bool reset);
>
> I felt the word 'config' in the name is not really required since the
> functionality is fixed (as opposed to the davinci_psc_config() function
> which could do multiple configurations)
>
> I updated the function name to davinci_psc_reset() when I committed the
> patch locally.
>
> Hope that's okay with you.
>
> Thanks,
> Sekhar
^ permalink raw reply
* [PATCH] am33xx: cpsw: default to ethernet hwaddr from efuse if not defined in dt
From: Tony Lindgren @ 2013-01-17 17:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <87a9s7lq09.fsf@dell.be.48ers.dk>
* Peter Korsgaard <jacmet@sunsite.dk> [130117 08:46]:
> >>>>> "Michal" == Michal Bachraty <michal.bachraty@gmail.com> writes:
>
> Hi Michael,
>
> Michal> I made changes to cpsw driver two weeks ago, which add support
> Michal> for reading MAC address from CPU and also I posted it to
> Michal> review. You can find patch here :
> Michal> https://patchwork.kernel.org/patch/1966481/ I will create
> Michal> updated patch next week, depended on reactions. Can you try
> Michal> that patch? I'll be glad to hear your opinion.
>
> Thanks, I missed that patch. Functionality wise the patches do the same,
> but I must say I find my patch cleaner, as it doesn't involve any new dt
> bindings or access to the am33xx specific control module registers from
> the cpsw driver.
>
> The way I've handled it is similar to how it is done on atleast one
> other arm subarchicture, see
> arch/arm/mach-mxs/mach-mxs.c::update_fec_mac_prop()
Cool this seems like the cleanest way to deal with it so far. Can
you please resend with also linux-net and DT list Cc:d too?
Also the arch_initcall should be omap_arch_initcall in linux next
for consistency if we ever have SoC specific sections for those.
Regards,
Tony
^ permalink raw reply
* [kvmarm] [PATCH v6 02/13] KVM: ARM: Introduce KVM_SET_DEVICE_ADDRESS ioctl
From: Peter Maydell @ 2013-01-17 17:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130116180028.29393.62418.stgit@ubuntu>
On 16 January 2013 18:00, Christoffer Dall
<c.dall@virtualopensystems.com> wrote:
> KVM: ARM: Introduce KVM_SET_DEVICE_ADDRESS ioctl
Patch subject needs updating with new name of this ioctl
(KVM_ARM_SET_DEVICE_ADDR)...
> On ARM (and possibly other architectures) some bits are specific to the
> model being emulated for the guest and user space needs a way to tell
> the kernel about those bits. An example is mmio device base addresses,
> where KVM must know the base address for a given device to properly
> emulate mmio accesses within a certain address range or directly map a
> device with virtualiation extensions into the guest address space.
"virtualization", while I'm here.
> --- a/arch/arm/include/uapi/asm/kvm.h
> +++ b/arch/arm/include/uapi/asm/kvm.h
> @@ -65,6 +65,19 @@ struct kvm_regs {
> #define KVM_ARM_TARGET_CORTEX_A15 0
> #define KVM_ARM_NUM_TARGETS 1
>
> +/* KVM_SET_DEVICE_ADDRESS ioctl id encoding */
> +#define KVM_DEVICE_TYPE_SHIFT 0
> +#define KVM_DEVICE_TYPE_MASK (0xffff << KVM_DEVICE_TYPE_SHIFT)
> +#define KVM_DEVICE_ID_SHIFT 16
> +#define KVM_DEVICE_ID_MASK (0xffff << KVM_DEVICE_ID_SHIFT)
...and this comment and I guess these constant names presumably
should have "ARM" in them?
> +/* Available with KVM_CAP_SET_DEVICE_ADDR */
KVM_CAP_ARM_SET_DEVICE_ADDR.
-- PMM
^ 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