+ Chris since the patch has some davinci_mmc.c changes.
Chris, Mark,
On 3/6/2013 9:45 PM, Matt Porter wrote:
> Move mach-davinci/dma.c to common/edma.c so it can be used
> by OMAP (specifically AM33xx) as well.
>
> Signed-off-by: Matt Porter
> Acked-by: Sekhar Nori
Can you please ack changes
Mike,
On Mon, Jun 03, 2013 at 10:53:07AM -0700, Mike Turquette wrote:
> I am using this code while converting the OMAP4 clock data over to DT
I see these basic clk bindings can be useful for platforms that have
a relatively simple clock tree, but I'm a little surprised that you plan
to move OMAP4
On 5/28/2013 1:58 PM, Manjunathappa, Prakash wrote:
> For modules having single clock, clk_get should be done with dev_id.
> But current davinci implementation handles multiple instances
> of the UART devices with single platform_device_register. Hence clk_get
> is based on con_id rather than dev_i
As of now we rely on code outside of the driver to set the ciu clock
frequency. There's no reason to do that. Add support for setting up
the clock in the driver during probe.
Signed-off-by: Doug Anderson
---
.../devicetree/bindings/mmc/synopsis-dw-mshc.txt| 13 +
drivers/mm
It is possible to specify a regulator that should be turned on when
dw_mmc is probed. This regulator is optional, though a warning will
be printed if it's missing. The fact that the regulator is optional
means that (at the moment) it's not possible to use a regulator that
probes _after_ dw_mmc.
On Fri, Jun 7, 2013 at 8:48 AM, Mike Dunn wrote:
> On 06/06/2013 04:58 PM, Haojian Zhuang wrote:
>> On 7 June 2013 01:33, Mike Dunn wrote:
>>>
>
>
> [...]
>
>
>>>
>>> Yes, but currently pinctrl-single only supports writing one register for a
>>> given
>>> pin (with multiple pins sharing a regist
On Thu, Jun 06, 2013 at 05:54:42PM +0200, Philipp Zabel wrote:
> I'm not sure. Is this something that should be done unconditionally for
> fsl,data-width = <18>?
>
Ah, yes, that's better.
Shawn
___
devicetree-discuss mailing list
devicetree-discuss@lis
On 6 June 2013 23:30, Christian Ruppert wrote:
> On Thu, Jun 06, 2013 at 10:32:21PM +0800, Haojian Zhuang wrote:
>> On 6 June 2013 22:11, Christian Ruppert wrote:
>> > On Wed, Jun 05, 2013 at 09:44:27AM +0800, Haojian Zhuang wrote:
>> >> On 3 June 2013 20:30, Christian Ruppert
>> >> wrote:
>> >
On 7 June 2013 01:33, Mike Dunn wrote:
> Thanks for the reply Haojian.
>
> On 06/05/2013 05:43 PM, Haojian Zhuang wrote:
>> On 6 June 2013 01:23, Mike Dunn wrote:
>>> Hi,
>>>
>>> I'd like to start converting to device tree usage some of the old pxa27x
>>> platforms I'm fond of, starting with addi
From: Alexey Brodkin
Date: Tue, 4 Jun 2013 16:21:50 +0400
> +{
> + struct arc_emac_priv *priv = netdev_priv(net_dev);
> + struct phy_device *phydev = priv->phy_dev;
> + u32 reg;
> +
> + int status_change = 0;
Do not add empty lines amongst the top-level variable declarations
of a
On Thu, Jun 6, 2013 at 10:11 PM, Heiko Stübner wrote:
> Cortex-A9 SoCs from Rockchip use a slightly modified variant of dw_mmc
> controllers that seems to require the SDMMC_CMD_USE_HOLD_REG bit to
> always be set.
>
> There also seem to be no other modifications (additional register etc)
> present
On Thursday 06 June 2013, Maxime Ripard wrote:
> So yes, Allwinner has an evil vendor tree (c), with a solution similar yet
> inferior (because not generic enough) to the device tree, but they show
> interest on going down the mainline road.
Right, and of course there is nothing special about that
On Mon, Jun 3, 2013 at 1:59 AM, Heiko Stübner wrote:
> Cortex-A9 SoCs from Rockchip use a slightly modified variant of dw_mmc
> controllers that seems to require the SDMMC_CMD_USE_HOLD_REG bit to
> always be set.
>
> There also seem to be no other modifications (additional register etc)
> present,
With pbias support in place remove dt workaround for pbias
Signed-off-by: Balaji T K
---
drivers/mmc/host/omap_hsmmc.c | 20 +---
1 files changed, 1 insertions(+), 19 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 8dd1cd3..f2e3d1a
Since regulator_put can handle NULL / IS_ERR(regulator)
use_reg can be removed, so that regulator_put in omap_hsmmc_reg_put
can be reused for vmmc_aux regulator error scenario.
Signed-off-by: Balaji T K
---
drivers/mmc/host/omap_hsmmc.c |8 ++--
1 files changed, 2 insertions(+), 6 deleti
add pbias states for pbias 0, 1.8V, 3V
add omap3 sd/mmc2 loop back clock config for devconf1 in mmc2_init pinctrl state
add OMAP3430 sd/mmc1 loop back clock config for devconf0 in mmc1_init pinctrl
state
add OMAP3630 sd/mmc1 speed mode config for prog_io1 in mmc1_init pinctrl state
Signed-off-by:
add pbias states for pbias 0, 1.8V, 3V
add sd/mmc1 pull strength values for control_mmc1 in mmc_init pinctrl state
Signed-off-by: Balaji T K
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 34 +
arch/arm/boot/dts/omap4-sdp.dts | 34 ++
PBIAS register configuration is based on the regulator voltage
which supplies these pbias cells, sd i/o pads.
With PBIAS register address and bit definitions different across
omap[3,4,5], Simplify PBIAS configuration under three different
regulator voltage levels - O V, 1.8 V, 3 V. Corresponding pi
Update needs_vmmc with info passed from board file via platform
data pdata->needs_vmmc.
Use needs_vmmc/needs_vmmc_aux to check whether
regulator is mandatory and handle regulator errors
like EPROBE_DEFER properly
Signed-off-by: Balaji T K
---
drivers/mmc/host/omap_hsmmc.c | 65
This patch series adds support for configuring pbias register needed for
switching (ON/OFF, voltage scaling 3V, 1.8V) vmmc regulator suppling
OMAP mmc/sd1 i/o pads for device tree boot.
The control module registers are needed for mmc pbias i/o, speed mode
configuration of mmc1 and loopback clock co
handle vcc and vcc_aux independently
Signed-off-by: Balaji T K
---
drivers/mmc/host/omap_hsmmc.c |9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 1865321..bda1a42 100644
--- a/drivers/mmc/host/oma
Add needs_vmmc and needs_vmmc_aux to indicate whether regulator is
applicable so that omap_hsmmc can handle deferred probe error
properly for regulators.
Remove the assumption that vmmc_aux regulator to be available only if vmmc is
present. Platforms can have fixed-always-ON regulator for vmmc and/
omap3_pmx_core: padconf register are in two banks 0x48003000 to 0x48002268
and 0x480025c0 to 0x480025f8.
split omap3_pmx_core into 2 banks as register between 0x48002270 and 0x48002564
belongs to type pinctrl-single,bit-per-mux with access to certain bit
fields with bit field mask.
Signed-off-by:
update needs_vmmc, needs_vmmc_aux for dt boot
Signed-off-by: Balaji T K
---
drivers/mmc/host/omap_hsmmc.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 21fc152..08f4ca7 100644
--- a/drivers/mmc/host/
This adds a generic devicetree board file and a dtsi for boards
based on the RK3066a SoCs from Rockchip.
Apart from the generic parts (gic, clocks, pinctrl) the only components
currently supported are the timers, uarts and mmc ports (all DesignWare-
based).
Signed-off-by: Heiko Stuebner
---
arc
Uarts on all recent Rockchip SoCs are Synopsis DesignWare 8250 types.
Only their addresses vary very much.
This patch adds the necessary definitions to use any of the uart ports
for early debug purposes.
Signed-off-by: Heiko Stuebner
---
arch/arm/Kconfig.debug| 34
Cortex-A9 SoCs from Rockchip use a slightly modified variant of dw_mmc
controllers that seems to require the SDMMC_CMD_USE_HOLD_REG bit to
always be set.
There also seem to be no other modifications (additional register etc)
present, so to keep the footprint low, add this small variant to the
pltf
This adds basic support for clocks on Rockchip rk3066 SoCs.
The clock handling thru small dt nodes is heavily inspired by the
sunxi clk code.
The plls are currently read-only, as their setting needs more
investigation. This also results in slow cpu speeds, as the apll starts
at a default of 600mhz
This driver adds support the Cortex-A9 based SoCs from Rockchip,
so at least the RK2928, RK3066 (a and b) and RK3188.
Earlier Rockchip SoCs seem to use similar mechanics for gpio
handling so should be supportable with relative small changes.
Pull handling on the rk3188 is currently a stub, due to i
dw_mci_pltfm_remove gets exported and used by dw_mmc-exynos, so should
not be static.
Signed-off-by: Heiko Stuebner
Acked-by: Jaehoon Chung
Acked-by: Seungwon Jeon
---
drivers/mmc/host/dw_mmc-pltfm.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/dw_
SoCs like the Rockchip Cortex-A9 ones contain divider some clocks
that use the regular mechanisms for storage but allow only even
dividers and 1 to be used.
Therefore add a flag that lets _is_valid_div limit the valid dividers
to these values. _get_maxdiv is also adapted to return even values
for
There exist platforms, namely at least all Rockchip Cortex-A9 based ones,
that don't use the paradigm of reading-changing-writing the register contents,
but instead only write the changes to the register with a mask that indicates
the changed bits.
This patch adds flags and code to support the cas
Second version of basic Rockchip A9 support.
Changes since v1:
- addressed Linus Walleij's comments to the pinctrl driver, including the
move to generic pinconfig (hopefully I did catch all)
- renamed the clocks to use the SoC name of the initial user
as suggested by Olof Johansson
- fixed th
On Thursday 06 June 2013 23:09:37 Shawn Guo wrote:
>
> On Tue, May 28, 2013 at 02:20:07PM +0800, Huang Shijie wrote:
> > The WEIM(Wireless External Interface Module) works like a bus.
> > You can attach many different devices on it, such as NOR, onenand.
> >
> > In the case of i.MX6q-sabreauto, t
On Thu, Jun 06, 2013 at 07:28:10PM +0200, Maxime Ripard wrote:
> I should also add that Allwinner not only talked to us already, but also
> expressed interest in doing actual modern kernel development (like using
> "recently" introduced kernel frameworks, like the clk framework).
>
> I've received
On 06/06/2013 12:08 PM, Dave Martin wrote:
> On Thu, Jun 06, 2013 at 10:44:48AM -0600, Stephen Warren wrote:
>> On 06/06/2013 01:28 AM, Alexandre Courbot wrote:
>>> Boot loaders on some Tegra devices can be unlocked but do not let the
>>> system operate without SecureOS. SecureOS prevents access to
On Thu, Jun 06, 2013 at 10:44:48AM -0600, Stephen Warren wrote:
> On 06/06/2013 01:28 AM, Alexandre Courbot wrote:
> > Boot loaders on some Tegra devices can be unlocked but do not let the
> > system operate without SecureOS. SecureOS prevents access to some
> > registers and requires the operating
On Thu, 6 Jun 2013, James King wrote:
> If CPUs are marked as disabled in the devicetree, make sure they do
> not exist in the system CPU information and CPU topology information.
> In this case these CPUs will not be able to be added to the system later
> using hot-plug. This allows a single chip
Hi everyone,
On Thu, Jun 06, 2013 at 09:00:00AM -0700, Olof Johansson wrote:
> On Thu, Jun 6, 2013 at 8:13 AM, jonsm...@gmail.com wrote:
> > On Wed, Jun 5, 2013 at 7:54 PM, luke.leighton
> > wrote:
> >> augh. ok. solutions. what are the solutions here?
> >
> > Luke if you really want to fix
2013/6/6 Jean-Christophe PLAGNIOL-VILLARD
> On 10:39 Thu 06 Jun , Michal Simek wrote:
> > On 06/06/2013 10:29 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > > On 18:45 Fri 31 May , Michal Simek wrote:
> > >> On 05/31/2013 05:16 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > >>> On 15:57
On Thu, Jun 06, 2013 at 06:27:08PM +0200, Sebastian Hesselbarth wrote:
> This patch set introduces DT-aware irqchip and clocksource drivers for
> Marvell Orion SoCs (Kirkwood, Dove, Orion5x, MV78x00) and corresponding
> patches for Dove and Kirkwood to enable them for DT-boards.
>
> The irqchip dr
On Thu, Jun 06, 2013 at 06:27:08PM +0200, Sebastian Hesselbarth wrote:
> This patch set introduces DT-aware irqchip and clocksource drivers for
> Marvell Orion SoCs (Kirkwood, Dove, Orion5x, MV78x00) and corresponding
> patches for Dove and Kirkwood to enable them for DT-boards.
Looks broadly good
On 06/06/2013 01:28 AM, Alexandre Courbot wrote:
> Boot loaders on some Tegra devices can be unlocked but do not let the
> system operate without SecureOS. SecureOS prevents access to some
> registers and requires the operating system to perform certain
> operations through Secure Monitor Calls ins
On 06/06/2013 04:37 AM, Alex Courbot wrote:
> Hi Tomasz,
>
> On 06/06/2013 07:17 PM, Tomasz Figa wrote:
...
>> I think this patch could be split into several patches:
>> - add support for firmware
>> - split reset function
>> - add reset support using firmware.
>
> Mmm possibly yes, but I w
On 12:13 Mon 03 Jun , Michal Simek wrote:
> Hi,
>
Arnd can you take look on it again please
I'll take a look on it next week
Best Regards,
J.
> I have done more changes in the driver to support probing
> on little and big endian system where detection is done
> directly on the hardware.
> I
With recent support for true irqchip and clocksource drivers for Orion
SoCs, now make use of it on DT enabled Kirkwood boards.
This also introduces a new Kconfig option for legacy (non-DT) Kirkwood
where old code is moved out to and polishes DT board file a little bit.
Signed-off-by: Sebastian He
This patch add a DT enabled driver for timers found on Marvell Orion SoCs
(Kirkwood, Dove, Orion5x, and Discovery Innovation). It installs a free-
running clocksource on timer0 and a clockevent source on timer1.
Corresponding device tree documentation is also added.
Signed-off-by: Sebastian Hessel
This patch adds an irqchip driver for the main interrupt controller found
on Marvell Orion SoCs (Kirkwood, Dove, Orion5x, Discovery Innovation).
Corresponding device tree documentation is also added.
Signed-off-by: Sebastian Hesselbarth
---
Cc: Grant Likely
Cc: Rob Herring
Cc: Rob Landley
Cc:
With recent support for true irqchip and clocksource drivers for Orion
SoCs, now make use of it on DT enabled Dove boards.
Signed-off-by: Sebastian Hesselbarth
---
Cc: Grant Likely
Cc: Rob Herring
Cc: Rob Landley
Cc: Thomas Gleixner
Cc: John Stultz
Cc: Russell King
Cc: Jason Cooper
Cc: And
With recent support for true irqchip and clocksource drivers for Orion
SoCs, now make use of it on DT enabled Dove boards.
Signed-off-by: Sebastian Hesselbarth
---
Cc: Grant Likely
Cc: Rob Herring
Cc: Rob Landley
Cc: Thomas Gleixner
Cc: John Stultz
Cc: Russell King
Cc: Jason Cooper
Cc: And
This patch set introduces DT-aware irqchip and clocksource drivers for
Marvell Orion SoCs (Kirkwood, Dove, Orion5x, MV78x00) and corresponding
patches for Dove and Kirkwood to enable them for DT-boards.
The irqchip driver, of course, depends on Thomas Gleixner's work on
irqdomain support for gener
With recent support for true irqchip and clocksource drivers for Orion
SoCs, now make use of it on DT enabled Kirkwood boards.
Signed-off-by: Sebastian Hesselbarth
---
Cc: Grant Likely
Cc: Rob Herring
Cc: Rob Landley
Cc: Thomas Gleixner
Cc: John Stultz
Cc: Russell King
Cc: Jason Cooper
Cc:
On Thu, Jun 6, 2013 at 8:13 AM, jonsm...@gmail.com wrote:
> On Wed, Jun 5, 2013 at 7:54 PM, luke.leighton wrote:
>> augh. ok. solutions. what are the solutions here?
>
> Luke if you really want to fix this a good solution is to have
> Allwinner join Linaro and provide an engineer to the Linar
Hi Shawn,
Am Donnerstag, den 06.06.2013, 23:16 +0800 schrieb Shawn Guo:
> On Thu, Mar 28, 2013 at 04:23:30PM +0100, Philipp Zabel wrote:
> > +static void imx_ldb_encoder_prepare(struct drm_encoder *encoder)
> > +{
> > + struct imx_ldb_channel *imx_ldb_ch = enc_to_imx_ldb_ch(encoder);
> > + str
On 06/05/2013 09:34 PM, J, KEERTHY wrote:
> Hi Stephen,
>
> Thanks for the quick review.
>
> Stephen Warren wrote at Wednesday, June 05, 2013 10:44 PM:
>> On 06/04/2013 02:41 AM, J Keerthy wrote:
>>> From: Graeme Gregory
>>>
>>> Add the various binding files for the palmas family of chips. There
If a slave can use any of several DMA controllers on the system, multiple
DMA descriptors can be listed in its "dmas" DT property with the same
channel name and different DMA controller phandles. However, if multiple
such slaves can use any of a set of DMA controllers on the system, listing
them al
This patch adds Device Tree support to the shdma driver. No special DT
properties are used, only standard DMA DT bindings are implemented. Since
shdma controllers reside on SoCs, their configuration is SoC-specific and
shall be passed to the driver from the SoC platform data, using the
auxdata proc
Sometimes it is useful to group similar DT nodes under a common parent,
when a different node can reference the group, meaning, that any subnode
will do the job. An example of such a group is a DMA multiplexer, when a
DMA slave can be served by any DMA controller from the group. This patch
slightly
Next re-send of an earlier work. This series adds support for multiple
compatible DMAC instances, capable of serving the same DMA slaves.
Currently to specify such a configuration in DT, slaves would have to add
DMA tuples for each requested channel for each suitable DMAC. This
needlessly clutt
To use DMA in the Device Tree case the driver has to be modified
to use suitable API to obtain DMA channels.
Signed-off-by: Guennadi Liakhovetski
---
drivers/mmc/host/sh_mmcif.c | 29 ++---
1 files changed, 18 insertions(+), 11 deletions(-)
diff --git a/drivers/mmc/hos
Add support for initialising DMA from the Device Tree.
Signed-off-by: Guennadi Liakhovetski
---
drivers/mmc/host/sh_mobile_sdhi.c | 14 +++---
drivers/mmc/host/tmio_mmc_dma.c | 19 ---
2 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/drivers/mmc/host
So far only the SDHI implementation uses TMIO MMC with DMA. That way a DMA
channel filter function, defined in the TMIO driver wasn't a problem.
However, such a filter function is DMA controller specific. Since the SDHI
glue is only running on systems with the SHDMA DMA controller, the filter
funct
Also a re-send of four earlier submitted patches. This patch-series alone
is not enough to support DMA in DT on these MMC host controllers, support
in appropriate DMAC driver is added in a separate series. This, however,
doesn't introduce a dependency, series can be applied in arbitrary order.
This removes the deprecated use of the .private member of struct dma_chan
and switches the sdhi / tmio mmc driver to using the
dmaengine_slave_config() channel configuration method.
Cc: Samuel Ortiz
Signed-off-by: Guennadi Liakhovetski
Acked-by: Samuel Ortiz
---
drivers/mmc/host/sh_mobile_sdhi
On Wed, Jun 05, 2013 at 11:38:52PM +0100, Luke Kenneth Casson Leighton wrote:
> their sheer overwhelming success provides us with mass-volume
> ultra-low cost hardware. to not make an effort to accommodate them
> would in this specific instance be a huge missed opportunity,
> responsibility for w
On Thursday 06 June 2013, Shawn Guo wrote:
> Since no one is collecting drivers/bus/ patches right now, I just
> applied the whole series to have the patch go via imx -> arm-soc.
> Please let me know if there is any problem.
I think that's fine.
Arnd
__
On Thu, Mar 28, 2013 at 04:23:30PM +0100, Philipp Zabel wrote:
> +static void imx_ldb_encoder_prepare(struct drm_encoder *encoder)
> +{
> + struct imx_ldb_channel *imx_ldb_ch = enc_to_imx_ldb_ch(encoder);
> + struct imx_ldb *ldb = imx_ldb_ch->ldb;
> + struct drm_display_mode *mode = &en
On Tue, May 28, 2013 at 02:20:07PM +0800, Huang Shijie wrote:
> The WEIM(Wireless External Interface Module) works like a bus.
> You can attach many different devices on it, such as NOR, onenand.
>
> In the case of i.MX6q-sabreauto, the NOR is connected to WEIM.
>
> This patch also adds the devic
On Wed, Jun 5, 2013 at 7:54 PM, luke.leighton wrote:
> augh. ok. solutions. what are the solutions here?
Luke if you really want to fix this a good solution is to have
Allwinner join Linaro and provide an engineer to the Linaro effort.
That engineer will get educated on the right way to do ke
On Thu, Jun 6, 2013 at 7:02 AM, Theodore Ts'o wrote:
> On Thu, Jun 06, 2013 at 01:24:57PM +0100, luke.leighton wrote:
>> On Thu, Jun 6, 2013 at 1:01 AM, Tomasz Figa wrote:
>>
>> > I don't see any other solution here than moving all the Allwinner code to
>> > DT (as it has been suggested in this t
On 10:39 Thu 06 Jun , Michal Simek wrote:
> On 06/06/2013 10:29 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> > On 18:45 Fri 31 May , Michal Simek wrote:
> >> On 05/31/2013 05:16 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >>> On 15:57 Fri 31 May , Michal Simek wrote:
> On 05/31/
On 6 June 2013 22:11, Christian Ruppert wrote:
> On Wed, Jun 05, 2013 at 09:44:27AM +0800, Haojian Zhuang wrote:
>> On 3 June 2013 20:30, Christian Ruppert wrote:
>> > OK, here's a simplified example of what we would like to do (this seems
>> > pretty common so I suppose there is a way I haven't
On Thu, Jun 06, 2013 at 11:02:43AM -0300, Fabio Estevam wrote:
> You could try something like (pass the real clock in the device tree):
> http://permalink.gmane.org/gmane.linux.alsa.devel/107614
> (I will re-post this patch later)
That's exactly what I'm suggesting.
signature.asc
Description:
Hi Nicolin,
On Thu, Jun 6, 2013 at 9:49 AM, Nicolin Chen wrote:
> But I always got "failed to create fixed clk" error during system booting.
> So I think it's pretty different to get a fixed clock with normal since
> it's on the root_list of clock tree.
> How can I get the clock here, or more sp
On Thu, Jun 06, 2013 at 08:49:53PM +0800, Nicolin Chen wrote:
> On Wed, Jun 05, 2013 at 12:55:44PM +0100, Mark Brown wrote:
> > Since it's easy to define a fixed rate clock (there's a generic driver
> > for that) I'd just require the user to provide a clock API clock and fix
> > the rate using tha
On Thu, Jun 06, 2013 at 07:38:46PM +0800, Nicolin Chen wrote:
> +Optional properties:
> + - spk-mono: Default register value for SPK_MONO of R51 (Class D Control 2).
This doesn't correspond to the code. This is a boolean property, if
it's present then that bit gets set indicating that the speak
On Tue, Jun 04, 2013 at 01:07:07PM +0200, Steffen Trumtrar wrote:
> Markus Niebel (4):
> ARM i.MX53: mba53: add sound support
> ARM i.MX53: mba53: add missing gpio stuff for pca9554
> ARM i.MX53: mba53: use reset gpio for FEC
> ARM i.MX53: mba53: add DI1_CLK to pinctrl for disp1
>
> Michae
On Thu, Jun 06, 2013 at 07:38:45PM +0800, Nicolin Chen wrote:
> Embed a copy of struct wm8962_pdata in stuct wm8962_priv
> so that there's no need to check validity of pdata any more.
Applied, thanks.
signature.asc
Description: Digital signature
___
de
On Thu, Jun 06, 2013 at 11:49:36AM +0200, Steffen Trumtrar wrote:
> Add WP/CD pinctrl for esdhc2.
> Also, add vmmc-supply for esdhc2.
>
> Signed-off-by: Steffen Trumtrar
Applied, thanks.
Shawn
___
devicetree-discuss mailing list
devicetree-discuss@li
On Thu, Jun 06, 2013 at 01:22:04PM +0100, luke.leighton wrote:
> On Thu, Jun 6, 2013 at 1:19 AM, Henrik Nordström
> wrote:
> > tor 2013-06-06 klockan 00:54 +0100 skrev luke.leighton:
> >
> >> > Not really the case. Actually the opposite. DT have this as well, and
> >> > integrated in device probin
On Thu, Jun 06, 2013 at 01:24:57PM +0100, luke.leighton wrote:
> On Thu, Jun 6, 2013 at 1:01 AM, Tomasz Figa wrote:
>
> > I don't see any other solution here than moving all the Allwinner code to
> > DT (as it has been suggested in this thread several times already), as
> > this is the only hardw
On Thursday 06 of June 2013 13:49:38 luke.leighton wrote:
> On Thu, Jun 6, 2013 at 1:43 PM, Tomasz Figa
wrote:
> > Luke,
> >
> > On Thursday 06 of June 2013 13:24:57 luke.leighton wrote:
> >> On Thu, Jun 6, 2013 at 1:01 AM, Tomasz Figa
> >
> > wrote:
> >> > I don't see any other solution here
Highbank supports SGPIO by bit-banging out the SGPIO signals over
three GPIO pins defined in the DTB. Add support for this SGPIO
functionality.
Signed-off-by: Mark Langsdorf
---
Changes from v3:
Correctly mask the activity bits to clear bits in ecx_parse_sgpio()
Changes from v2:
A
Luke,
On Thursday 06 of June 2013 13:24:57 luke.leighton wrote:
> On Thu, Jun 6, 2013 at 1:01 AM, Tomasz Figa
wrote:
> > I don't see any other solution here than moving all the Allwinner code
> > to DT (as it has been suggested in this thread several times
> > already), as this is the only hardw
> so the point is: if anyone wishes me to propose to allwinner that
> they convert over to devicetree, or any other proposal which involves
> significant low-level changes to their working practices that could
> potentially have a massive knock-on effect onto their
> multi-million-dollar clients,
On Thu, Jun 6, 2013 at 12:58 PM, Alexandre Courbot wrote:
> Boot loaders on some Tegra devices can be unlocked but do not let the
> system operate without SecureOS. SecureOS prevents access to some
> registers and requires the operating system to perform certain
> operations through Secure Monitor
,On 06/05/2013 06:15 PM, Tejun Heo wrote:
> Hello,
>
> On Wed, Jun 05, 2013 at 05:31:48PM -0500, Mark Langsdorf wrote:
>> +static void ecx_parse_sgpio(struct ecx_plat_data *pdata, u32 port, u32
>> state)
>> +{
>> +if (state & ECX_ACTIVITY_BITS)
>> +pdata->sgpio_pattern |= sgpio_bi
On Thu, Jun 6, 2013 at 9:39 AM, Michal Simek wrote:
> On 06/06/2013 10:29 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
>> On 18:45 Fri 31 May , Michal Simek wrote:
>>> ok. good to know. Btw: Let's return to my origin point why not to
>>> export of_irq_count for modules?
>>> Or opposite question
On Thu, Jun 06, 2013 at 12:17:02PM +0200, Tomasz Figa wrote:
> Hi Alex,
>
> On Thursday 06 of June 2013 16:28:07 Alexandre Courbot wrote:
> > Boot loaders on some Tegra devices can be unlocked but do not let the
> > system operate without SecureOS. SecureOS prevents access to some
> > registers an
On Thu, Jun 06, 2013 at 04:28:07PM +0900, Alexandre Courbot wrote:
> Boot loaders on some Tegra devices can be unlocked but do not let the
> system operate without SecureOS. SecureOS prevents access to some
> registers and requires the operating system to perform certain
> operations through Secure
Hi,
On Fri, May 31, 2013 at 08:38:45PM +0200, Michael Grzeschik wrote:
> From: Michael Grzeschik
>
> This patch makes it possible to configure the PTW, PTS and STS bits
> inside the portsc register for host and device mode before the driver
> starts and the phy can be addressed as hardware imple
On Jun 6, 2013, at 12:07 AM, Luke Kenneth Casson Leighton wrote:
> [ please do try to remove debian-release from replies - my mistake
> please try not to propagage it, even though it may be too late!]
>
> On Wed, Jun 5, 2013 at 10:16 PM, Russell King - ARM Linux
> wrote:
>
> eyy, allo russell
On 6/6/2013 4:02 PM, Sekhar Nori wrote:
> Hi Prakash,
>
> It appears that this patch was not tested thoroughly. See below:
>
> On 5/28/2013 1:58 PM, Manjunathappa, Prakash wrote:
>> For modules having single clock, clk_get should be done with dev_id.
>> But current davinci implementation handle
linux/kernel/git/next/linux-next.git/tree/arch/arm/mach-exynos/exynos-smc.S?id=refs/tags/next-20130606
Yes, I just embarrassed myself showing my ignorance of ARM assembler. ;)
The fix Russel proposed is pretty close to your version.
+static const struct firmware_ops tegra_firmw
Hi Prakash,
It appears that this patch was not tested thoroughly. See below:
On 5/28/2013 1:58 PM, Manjunathappa, Prakash wrote:
> For modules having single clock, clk_get should be done with dev_id.
> But current davinci implementation handles multiple instances
> of the UART devices with single
On Thu, Jun 06, 2013 at 01:08:56PM +0300, Illia Smyrnov wrote:
> On 06/05/2013 03:03 PM, Mark Brown wrote:
> >Why is this defined for slaves? Surely the size of the FIFO in the
> >controller is a property of the controller not the slave?
> According to OMAP TRM [1] the FIFO buffer can be used by
On 6/5/2013 5:11 PM, Sekhar Nori wrote:
>
> On 5/28/2013 1:58 PM, Manjunathappa, Prakash wrote:
>> 1) "struct davinci_uart_config" is introduced to specify
>>UART ports brought out or enabled on the board. But
>>none of the boards use them for that purpose, so clean
>>it up.
>> 2) Have
On 06/06/2013 06:35 PM, Russell King - ARM Linux wrote:
On Thu, Jun 06, 2013 at 04:28:07PM +0900, Alexandre Courbot wrote:
+static int __attribute__((used)) __tegra_smc_stack[10];
+
+/*
+ * With EABI, subtype and arg already end up in r0, r1 and r2 as they are
+ * function arguments, but we pref
On Thu, Jun 06, 2013 at 01:08:46PM +0300, Illia Smyrnov wrote:
> On 06/05/2013 02:57 PM, Mark Brown wrote:
> Turbo mode gives the expected results not for all cases. There are
> some limitations:
> - works only if a single channel is enabled (no effect when several
> channels are enable);
> - impr
On Thu, Jun 06, 2013 at 02:01:14AM +0200, Tomasz Figa wrote:
> I don't see any other solution here than moving all the Allwinner code to
> DT (as it has been suggested in this thread several times already), as
> this is the only hardware description method supported by ARM Linux.
Well, the serv
1 - 100 of 133 matches
Mail list logo
