Hi,
On Wed, Oct 31, 2012 at 06:17:02AM +0100, Hebbar, Gururaja wrote:
> On Mon, Oct 29, 2012 at 21:47:19, Balbi, Felipe wrote:
> > Hi,
> >
> > On Mon, Oct 29, 2012 at 06:26:48PM +0530, Hebbar, Gururaja wrote:
> > > HSMMC IP on AM33xx need a special setting to handle High-speed cards.
> > > Other
* Pantelis Antoniou [121030 13:18]:
> On Oct 30, 2012, at 9:39 PM, Tony Lindgren wrote:
>
> > * Pantelis Antoniou [121030 12:00]:
> >> +
> >> + priv->lcdc_oh = omap_hwmod_lookup("lcdc");
> >> + if (priv->lcdc_oh == NULL) {
> >> + dev_err(&pdev->dev, "Failed to lookup omap_hwmod lcdc\n
On Tuesday, October 30, 2012 10:51:11 PM Linus Walleij wrote:
> On Tue, Oct 30, 2012 at 7:37 PM, Mark Brown
> wrote:
>
> > More seriously the amount of time we seem to have been spending recently
> > on changes which end up requiring us to go through essentially every
> > driver and add code to t
Hi Thomas,
On 10/29/2012 11:09 AM, Thomas Abraham wrote:
> Hi Sylwester,
>
> Thanks for your comments. As usual, your comments are very helpful.
Thanks.
> On 22 October 2012 21:25, Sylwester Nawrocki wrote:
>> Hi Thomas,
>>
>> On 10/07/2012 07:10 PM, Thomas Abraham wrote:
>>> All Samsung platfo
On Tue, 30 Oct 2012 16:24:05 -0600
Stephen Warren wrote:
> On 10/30/2012 03:57 PM, Kim Phillips wrote:
> > Projects such as linux and u-boot run sparse on libfdt. libfdt
> > contains the notion of endianness via usage of endian conversion
> > functions such as fdt32_to_cpu. As such, in order to
On 10/30/2012 03:57 PM, Kim Phillips wrote:
> Projects such as linux and u-boot run sparse on libfdt. libfdt
> contains the notion of endianness via usage of endian conversion
> functions such as fdt32_to_cpu. As such, in order to pass endian
> checks, libfdt has to annotate its fdt variables as
Projects such as linux and u-boot run sparse on libfdt. libfdt
contains the notion of endianness via usage of endian conversion
functions such as fdt32_to_cpu. As such, in order to pass endian
checks, libfdt has to annotate its fdt variables as big endian.
This patch does that ifdef __CHECKER__ (
On Tue, Oct 30, 2012 at 7:37 PM, Mark Brown
wrote:
> More seriously the amount of time we seem to have been spending recently
> on changes which end up requiring us to go through essentially every
> driver and add code to them (often several times) doesn't seem like
> we're doing a good job here.
* Pantelis Antoniou [121030 12:00]:
> +
> + priv->lcdc_oh = omap_hwmod_lookup("lcdc");
> + if (priv->lcdc_oh == NULL) {
> + dev_err(&pdev->dev, "Failed to lookup omap_hwmod lcdc\n");
> + return -ENODEV;
> + }
> +
> + priv->lcdc_pdev = omap_device_build("da8x
* Pantelis Antoniou [121030 12:00]:
> +#include
> +#include
We already have queued patches to make omap_device.h
private to arch/arm/mach-omap2. Then plat/clock.h will
be gone with the common clock framework patches.
Regards,
Tony
___
devicetree-dis
Hi,
On Tue, Oct 30, 2012 at 11:20:07AM -0700, Dmitry Torokhov wrote:
> On Tue, Oct 30, 2012 at 07:25:13PM +0200, Felipe Balbi wrote:
> > On Tue, Oct 30, 2012 at 03:58:21PM +, Mark Brown wrote:
> > >
> > > But then this comes round to the mindless code that ought to be factored
> > > out :) O
On Tue, Oct 30, 2012 at 07:25:13PM +0200, Felipe Balbi wrote:
> On Tue, Oct 30, 2012 at 03:58:21PM +, Mark Brown wrote:
> > But then this comes round to the mindless code that ought to be factored
> > out :) Only the more interesting cases that do something unusual really
> > register here.
Signed-off-by: Gregory CLEMENT
---
arch/arm/boot/dts/armada-370.dtsi | 12 +
arch/arm/boot/dts/armada-xp.dtsi| 48 +++
arch/arm/mach-mvebu/Kconfig |5
arch/arm/mach-mvebu/armada-370-xp.c |8 +-
arch/arm/mach-mvebu/common.h
Signed-off-by: Gregory CLEMENT
cc: John Stultz
---
arch/arm/boot/dts/armada-370-db.dts |4
arch/arm/boot/dts/armada-370-xp.dtsi |1 +
drivers/clocksource/time-armada-370-xp.c | 11 ++-
3 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dt
Add Armada 370/XP specific clocks: core clocks and CPU clocks.
The CPU clocks are only for Armada XP for the SMP mode.
The core clocks are clocks which have their rate set during reset. The
code was written with the other SoCs of the mvebu family in
mind. Adding them should be pretty straight for
Hello Mike,
I hope this 4th version will meet your expectations. Beside the
corrections you have asked I also changed the way I get resources for
the clocks. Instead of referring to a node name, now I refer to a
compatible name which should be a better use of the device tree.
Rather than taking t
On Tue, Oct 30, 2012 at 07:25:13PM +0200, Felipe Balbi wrote:
> On Tue, Oct 30, 2012 at 03:58:21PM +, Mark Brown wrote:
> >
> > But then this comes round to the mindless code that ought to be factored
> > out :) Only the more interesting cases that do something unusual really
> > register her
On 10/29/2012 12:32 PM, Mike Turquette wrote:
> Quoting Stephen Warren (2012-10-23 14:45:56)
>> What do people think of this? Does it sound like a good idea to go ahead
>> with a reset subsystem? Should we simply add a new API to the common clock
>> subsystem instead (and assume that reset and cloc
Hi,
On Tue, Oct 30, 2012 at 03:58:21PM +, Mark Brown wrote:
> > > > and this is one of the issues we're all trying to solve today so we have
> > > > single zImage approach for the ARM port.
>
> > > I don't see the relevance of single zImage here; device tree is supposed
> > > to solve that on
Hi Thomas,
Quoting Thomas Abraham (2012-10-07 10:10:51)
> +/* determine the output clock speed of the pll */
> +static unsigned long samsung_pll_clock_recalc_rate(struct clk_hw *hw,
> + unsigned long parent_rate)
> +{
> + struct samsung_pll_clock *clk_pll = to_c
On 10/30/2012 11:07 AM, Wolfgang Grandegger wrote:
+ /* AHB bus error interrupts (not CAN bus errors) - shut down the
+* device.
+*/
+ if (sources & (GRCAN_IRQ_TXAHBERR | GRCAN_IRQ_RXAHBERR)) {
+ if (sources & GRCAN_IRQ_TXAHBERR) {
+
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/30/2012 05:07 PM, Mark Brown :
> On Mon, Oct 22, 2012 at 06:17:55PM +0800, Bo Shen wrote:
>> Using platform device id to check whether the Atmel SOC support
>> dma for data transfer
>>
>> If match "at91rm9200_ssc" which does not support DMA tran
On 10/22/2012 12:17 PM, Bo Shen :
> Add Atmel SSC for device tree support.
>
> Signed-off-by: Bo Shen
> ---
> .../devicetree/bindings/misc/atmel-ssc.txt | 15 ++
> arch/arm/boot/dts/at91sam9260.dtsi |8
> arch/arm/boot/dts/at91sam9263.dtsi |
On Mon, Oct 22, 2012 at 06:17:55PM +0800, Bo Shen wrote:
> Using platform device id to check whether the Atmel SOC support dma for
> data transfer
>
> If match "at91rm9200_ssc" which does not support DMA transfer
> If match "at91sam9g45_ssc" which support DMA transfer
Any comments on this from th
On Tue, Oct 30, 2012 at 05:16:42PM +0200, Felipe Balbi wrote:
> On Tue, Oct 30, 2012 at 02:07:15PM +, Mark Brown wrote:
> > > and all of that SoC-specific detail is already hidden behind power
> > > domains, runtime PM, pinctrl, clk API, regulator framework, etc.
> > That's all getting rather
Hi,
On Tue, Oct 30, 2012 at 02:07:15PM +, Mark Brown wrote:
> On Tue, Oct 30, 2012 at 01:49:49PM +0200, Felipe Balbi wrote:
> > On Tue, Oct 30, 2012 at 11:24:10AM +, Mark Brown wrote:
>
> > > We need some place to put the SoC integration; power domains seem like
> > > the obvious place to
On Tue, Oct 30, 2012 at 03:16:02PM +0100, Linus Walleij wrote:
> On Tue, Oct 30, 2012 at 3:07 PM, Mark Brown
> > Essentially all the patches I'm seeing adding pinctrl are totally
> > mindless, most of them are just doing the initial setup on boot and not
> > doing any active management at runtime
On Tue, Oct 30, 2012 at 03:02:23PM +0100, Linus Walleij wrote:
> I worry that we will end up with power/resource domain
> code that start to look like this:
> suspend()
> switch (device.id) {
> case DEV_FOO:
> clk_disable();
> pinctrl_set_state();
> power_domain_off();
> case DEV_BAR:
Well
On Tue, Oct 30, 2012 at 3:07 PM, Mark Brown
wrote:
> Essentially all the patches I'm seeing adding pinctrl are totally
> mindless, most of them are just doing the initial setup on boot and not
> doing any active management at runtime at all.
None of the Ux500 pinctrl patches are like that.
I co
On Wed, Oct 03, 2012 at 18:06:10, Linus Walleij wrote:
> On Wed, Oct 3, 2012 at 12:52 PM, AnilKumar, Chimata wrote:
> > On Tue, Oct 02, 2012 at 01:29:37, Linus Walleij wrote:
>
> >> This is what we're doing for ux500 and should be a good model.
> >
> > I have looked into this, but not seen any na
On Tue, Oct 30, 2012 at 12:49 PM, Felipe Balbi wrote:
> On Tue, Oct 30, 2012 at 11:24:10AM +, Mark Brown wrote:
>> We need some place to put the SoC integration; power domains seem like
>> the obvious place to me but YMMV. Nothing about having this out of the
>
> except that pin muxing has n
On Tue, Oct 30, 2012 at 01:49:49PM +0200, Felipe Balbi wrote:
> On Tue, Oct 30, 2012 at 11:24:10AM +, Mark Brown wrote:
> > We need some place to put the SoC integration; power domains seem like
> > the obvious place to me but YMMV. Nothing about having this out of the
> except that pin muxi
On Tue, Oct 30, 2012 at 12:34 PM, Mark Brown
wrote:
> On Sun, Oct 28, 2012 at 09:12:52PM +0100, Linus Walleij wrote:
>> Moving this handling to bus code or anywhere else
>> invariably implies that resource acquisition/release order
>> does not matter, and my point is that it does.
>
> Doing this
On Sat, Oct 20, 2012 at 04:30:59, Dmitry Torokhov wrote:
> On Fri, Oct 19, 2012 at 12:36:12PM +0530, AnilKumar Ch wrote:
> > Remove const from pointer to array of gpios in matrix_keypad_platform_data
> > struct. This is required if we update row_gpios and col_gpios based on
> > device tree data.
>
Hi Rob,
Thanks for the comments.
On Fri, Oct 19, 2012 at 18:27:21, Rob Herring wrote:
> On 10/19/2012 02:06 AM, AnilKumar Ch wrote:
> > Add device tree support to matrix keypad driver and usage details
> > are added to device tree documentation. Driver was tested on AM335x
> > EVM.
> >
> > Signe
Hi,
On Tue, Oct 30, 2012 at 11:24:10AM +, Mark Brown wrote:
> > This is why I think hiding things from drivers makes no sense. Also
> > consider the situations Linus W exposed on another subthread. If you
> > change ordering of certain calls, you will really break the
> > functionality of the
On 10/30/2012 12:20 PM, Mike Turquette wrote:
> Quoting Gregory CLEMENT (2012-10-01 14:12:04)
>> Add Armada 370/XP specific clocks: core clocks and CPU clocks.
>>
>> The CPU clocks are only for Armada XP for the SMP mode.
>>
>> The core clocks are clocks which have their rate set during reset. The
On Sun, Oct 28, 2012 at 09:12:52PM +0100, Linus Walleij wrote:
> The answer is that it does not know. Because drivers have
> different needs. Depending on how the hardware and
> system is done.
...
> I'm not making this up, it is a very real phenomenon on the
> Ux500 and I don't think we are uni
On Mon, Oct 29, 2012 at 09:49:01PM +0200, Felipe Balbi wrote:
> On Fri, Oct 26, 2012 at 05:03:16PM +0100, Mark Brown wrote:
> > You could have the driver explicitly set the flag, it would just be one
> > extra line, but it seems marginally nicer to just do it.
> You didn't get the whole picture I
Hi Andreas,
sorry for late answer. Other duties are keeping me busy. Your v3
triggered a closer look...
On 10/24/2012 03:31 PM, Andreas Larsson wrote:
> On 10/23/2012 06:26 PM, Wolfgang Grandegger wrote:
>> Hi,
>>
>> before I have a closer look I have some general questions, especially
>> about t
On Mon, Oct 29, 2012 at 12:27 PM, Kukjin Kim wrote:
> On 10/29/12 19:28, Tomasz Figa wrote:
>> On Monday 29 of October 2012 09:30:26 Kyungmin Park wrote:
>> Since this depends on the patch adding Exynos4x12 dts files
>> ([PATCH] ARM: dts: exynos4: Add support for Exynos4x12 SoCs),
>> which will
Hi Sourav,
On 10/30/2012 6:26 AM, Sourav wrote:
Hi Benoit,
On Monday 29 October 2012 10:14 PM, Benoit Cousson wrote:
Hi Sourav,
On 10/29/2012 11:40 AM, Sourav Poddar wrote:
Add keypad data node in omap5-evm.
Based on I2C support patch for omap5, which has been
already posted as a different s
This driver supports GRCAN and CRHCAN CAN controllers available in the GRLIB
VHDL IP core library.
Signed-off-by: Andreas Larsson
---
Documentation/ABI/testing/sysfs-class-net-grcan| 35 +
.../devicetree/bindings/net/can/grcan.txt | 27 +
Documentation/kernel-parameters.txt
43 matches
Mail list logo
