On 13.11.2013 21:39, Tomasz Figa wrote:
> On Wednesday 13 of November 2013 20:35:22 Florian Meier wrote:
>> On 13.11.2013 19:43, Tomasz Figa wrote:
diff --git a/Documentation/devicetree/bindings/dma/bcm2835-dma.txt
b/Documentation/devicetree/bindings/dma/bcm2835-dma.txt
ne
Stephen Warren wrote @ Wed, 13 Nov 2013 18:58:23 +0100:
> > smmu: iommu@xx {
> >#iommu-cells = <3>;
> >^^
> >};
> >
> >host1x {
> >compatible = "nvidia,tegra30-host1x", "simple-bus";
> >iommu = <&smmu 0x??? 0x??? "asid"
Hi,
On Monday 07 October 2013 07:35 PM, Yuvaraj Cd wrote:
> On Tue, Oct 1, 2013 at 6:21 PM, Kishon Vijay Abraham I wrote:
>> On Tuesday 01 October 2013 12:03 PM, Yuvaraj Kumar C D wrote:
>>> This patch adds the sata phy driver for Exynos5250.Exynos5250 sata
>>> phy comprises of CMU and TRSV block
On Wed, Nov 13, 2013 at 08:11:18PM +0100, Lucas Stach wrote:
> Far better readablitity and no need to look up numbers
s/Far/For as well as patch #3.
Shawn
> in the documentation.
>
> Signed-off-by: Lucas Stach
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the bod
On Wed, Nov 13, 2013 at 08:11:17PM +0100, Lucas Stach wrote:
> +#define IMX5_CLK_SPDIF0_COM_SEL 181
> +#define IMX5_CLK_SPDIF1_COM_SEL 182
> +#define IMX5_CLK_SPDIF0_GATE 183
> +#define IMX5_CLK_SPDIF1_GATE 184
> +#define IMX5_CLK_SPDIF_IPG_GATE
On Wed, Nov 13, 2013 at 08:11:16PM +0100, Lucas Stach wrote:
> This series introduces devicetree includes for the i.MX5
> SoC clocks. It makes devicetrees easier to read for humans and
> less error prone.
>
> The series is spun against Shawns for-next branch, as there are
> already some clock rela
Looks like we're missing few entries for omap2 and the drivers
have only worked because of the omap hwmod building the devices
for the missing entries.
Let's fix the missing entries so we don't need to rely on hwmod
for the basic data and can then later on remove the duplicate
data from hwmod. Oth
Commit 89ce376c6bdc (drivers/net: Use of_match_ptr() macro in smc91x.c)
added minimal device tree support to smc91x, but it's not working on
many platforms because of the lack of some key configuration bits.
Fix the issue by parsing the necessary configuration like the
smc911x driver is doing.
Cc
On Wed, 13 Nov 2013 10:03:37 +0100, Pantelis Antoniou
wrote:
> On Nov 13, 2013, at 2:34 AM, Grant Likely wrote:
> > On Tue, 12 Nov 2013 11:39:08 +0100, Pantelis Antoniou
> > wrote:
> >>> On Tue, 5 Nov 2013 19:50:16 +0200, Pantelis Antoniou
> >>> wrote:
> +} else {
> +
On Tue, 12 Nov 2013 10:30:37 +0100, Pantelis Antoniou
wrote:
> Hi Grant,
>
> On Nov 11, 2013, at 7:42 PM, Grant Likely wrote:
>
> > On Fri, 8 Nov 2013 17:06:09 +0200, Pantelis Antoniou
> > wrote:
> >> Introduce DT overlay support.
> >> Using this functionality it is possible to dynamically o
On Tue, 12 Nov 2013 12:26:14 -0600, Kumar Gala wrote:
>
> On Nov 12, 2013, at 11:40 AM, Sebastian Andrzej Siewior
> wrote:
>
> > The document says "first four bits" and means the upper nibble. Most
> > people would probably agree that the first four bits are bits 0â¦3 and
> > that is the lowe
On Wed, Nov 13, 2013 at 10:13 PM, Mark Brown wrote:
> On Wed, Nov 13, 2013 at 08:40:54AM +0100, Krzysztof Kozlowski wrote:
>
>> +/**
>> + * After resuming from suspend it may happen that IRQ is signalled but
>> + * IRQ GPIO is not high. Also the interrupt registers won't have any data
>> + * (all
On 11/14/2013 02:57 AM, Olof Johansson wrote:
On Tue, Nov 12, 2013 at 6:14 PM, Alex Courbot wrote:
On 11/13/2013 05:38 AM, Olof Johansson wrote:
On Tue, Nov 12, 2013 at 12:26 PM, Stephen Warren
wrote:
On 11/07/2013 03:11 AM, Alexandre Courbot wrote:
Just a set of small fixes to address t
On 13-11-11 02:01 AM, Linus Walleij wrote:
I would imagine that the platform-specific device tree bindings would need
to clearly explain what the valid values are, as they should.
But this is not a platform-specific binding. These are the
generic pin configuration bindings we're talking about.
Per the ePAPR v1.1 specification, 'phy-connection-type' is the canonical
property name for describing an Ethernet to PHY connection type. Make
sure that of_get_phy_mode() also attempts to parse that property and
update the comments mentioninng 'phy-mode' to also include
'phy-connection-type'.
Sign
On 11/13/2013 03:29 PM, Mark Brown wrote:
> On Wed, Nov 13, 2013 at 02:59:01PM -0700, Stephen Warren wrote:
>> On 11/13/2013 01:49 PM, Mark Brown wrote:
>
>>> No, with DT you can say that if there is no DT binding configuring
>>> a given thing (clock, regulator, GPIO or whatever) then no amount
>>
Hi,
On Wed, Nov 13, 2013 at 02:24:06PM +, Mark Rutland wrote:
> > Current suggestions (taken from kernel) are:
> >
> > * <>,no-autorepeat
> > * keypad,autorepeat
> > * linux,keypad-no-autorepeat
> > * linux,input-no-autorepeat
> > * linux,no-autorepeat
> > * autorepeat
> >
> > I do not reall
On Wed, Nov 13, 2013 at 02:59:01PM -0700, Stephen Warren wrote:
> On 11/13/2013 01:49 PM, Mark Brown wrote:
> > No, with DT you can say that if there is no DT binding configuring
> > a given thing (clock, regulator, GPIO or whatever) then no amount
> > of module loading will ever cause it to appea
Hi Andy,
On Wednesday 30 of October 2013 15:31:05 Andy Gross wrote:
> On Tue, Oct 29, 2013 at 10:56:03AM -0700, Stephen Boyd wrote:
> > On 10/25, Andy Gross wrote:
> > > diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
> > > index f238cfd..a71b415 100644
> > > --- a/drivers/dma/Kconfig
> > >
On 11/13/2013 01:49 PM, Mark Brown wrote:
> On Wed, Nov 13, 2013 at 01:13:06PM -0700, Stephen Warren wrote:
>> On 11/13/2013 12:07 PM, Mark Brown wrote:
>
>>> This isn't really regulator specific - it's something that
>>> applies in general to things implementing deferred probing - so
>>> we ought
The frequency of some fixed rate external oscillators on some SoCs (for
example TZ1090's XTAL1) are specified by the board using pull-ups and
pull-downs of configuration pins which are automatically latched on
reset and available in an SoC register, so that the boot ROM and OS can
automatically dis
The frequency of some fixed rate external oscillators on some SoCs (for
example TZ1090's XTAL1) are specified by the board using pull-ups and
pull-downs of configuration pins which are automatically latched on
reset and available in an SoC register, so that the boot ROM and OS can
automatically dis
Implement the new specified-clock DT binding which uses a table to look
up the fixed frequency based on the value in a register.
The discovery is done entirely within of_specified_clk_setup() since the
clock rate is still fixed so there's no need to dynamically rediscover
the rate. The register is
On Wed, Nov 13, 2013 at 06:48:12PM +0530, Vinod Koul wrote:
> On Thu, Nov 07, 2013 at 05:03:17PM -0600, Andy Gross wrote:
> > On Thu, Oct 31, 2013 at 04:46:21PM -0500, Andy Gross wrote:
> > > On Thu, Oct 31, 2013 at 10:29:48PM +0530, Vinod Koul wrote:
> > > > On Fri, Oct 25, 2013 at 03:24:02PM -050
On Wed, Nov 13, 2013 at 01:13:06PM -0700, Stephen Warren wrote:
> On 11/13/2013 12:07 PM, Mark Brown wrote:
> > This isn't really regulator specific - it's something that applies
> > in general to things implementing deferred probing - so we ought to
> > have a generic "we know if devices can appe
On Tue, Nov 12, 2013 at 9:47 AM, Brian Norris
wrote:
> + DT maintainers, since they haven't responded
>
> On Mon, Nov 11, 2013 at 9:26 PM, Huang Shijie wrote:
>> 于 2013年11月07日 18:07, Huang Shijie 写道:
>>
>>> In default way, we use the ecc_strength/ecc_step size calculated by
>>> ourselves
>>> and
On Wednesday 13 of November 2013 20:35:22 Florian Meier wrote:
> On 13.11.2013 19:43, Tomasz Figa wrote:
> > Hi Florian,
> >
> > Seems like I accidentally replied to some old version of this patch.
> > Not sure how many of those comments were still relevant for V3, but
> > let me look at this vers
On Wed, 13 Nov 2013, Tomasz Figa wrote:
On Wednesday 13 of November 2013 13:10:51 Brian Austin wrote:
On Wed, 13 Nov 2013, Tomasz Figa wrote:
+0x00 through 0x0F.
+Frequency = (64xFs)/(N+2)
I suppose N means the value of chgfreq property here, but this shoul
On 11/13/2013 12:07 PM, Mark Brown wrote:
> On Wed, Nov 13, 2013 at 10:29:07AM -0700, Stephen Warren wrote:
>
>> It seems slightly odd to tightly link the drivers/of and
>> drivers/regulator code like that, but I guess with the
>> appropriate ifdefs it'll work out OK.
>
> This isn't really regul
On Wednesday 13 of November 2013 19:49:15 Mark Brown wrote:
> On Wed, Nov 13, 2013 at 07:24:04PM +0100, Tomasz Figa wrote:
>
> > Well, the label is just for the parser and it does not get into the DTB.
> > This is where the DTS author can make things up just for their own
> > convenience (like mai
On Wed, Nov 13, 2013 at 07:24:04PM +0100, Tomasz Figa wrote:
> Well, the label is just for the parser and it does not get into the DTB.
> This is where the DTS author can make things up just for their own
> convenience (like main_codec, aux_codec or even cs42l52).
If only we could have comments
Hi Russell,
On Wednesday 13 November 2013 19:12:30 Russell King - ARM Linux wrote:
> On Wed, Nov 13, 2013 at 11:43:44AM -0700, Troy Kisky wrote:
> > On 11/13/2013 2:23 AM, Denis Carikli wrote:
> >> +/* rgb666 */
> >>
> >> + ipu_dc_map_clear(priv, IPU_DC_MAP_RGB666);
> >> + ipu_dc_map_
On 13.11.2013 19:43, Tomasz Figa wrote:
> Hi Florian,
>
> Seems like I accidentally replied to some old version of this patch.
> Not sure how many of those comments were still relevant for V3, but
> let me look at this version and see whether we can still improve things
> a bit. Please see my comm
On Wednesday 13 of November 2013 13:10:51 Brian Austin wrote:
> On Wed, 13 Nov 2013, Tomasz Figa wrote:
>
> + 0x00 through 0x0F.
> + Frequency = (64xFs)/(N+2)
> >>>
> >>> I suppose N means the value of chgfreq property here, but this should be
> >>> clearl
On Wed, Nov 13, 2013 at 11:43:44AM -0700, Troy Kisky wrote:
> On 11/13/2013 2:23 AM, Denis Carikli wrote:
>> + /* rgb666 */
>> +ipu_dc_map_clear(priv, IPU_DC_MAP_RGB666);
>> +ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 2, 17, 0xfc); /* red */
>> +ipu_dc_map_config(priv, IPU_DC_MAP_RGB
This series introduces devicetree includes for the i.MX5
SoC clocks. It makes devicetrees easier to read for humans and
less error prone.
The series is spun against Shawns for-next branch, as there are
already some clock related patches in there. I would like to
see those patches sitting in -next
Far better readablitity and no need to look up numbers
in the documentation.
Signed-off-by: Lucas Stach
---
arch/arm/boot/dts/imx51.dtsi | 98 +++-
1 file changed, 61 insertions(+), 37 deletions(-)
diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot
Far better readablitity and no need to look up numbers
in the documentation.
Signed-off-by: Lucas Stach
---
arch/arm/boot/dts/imx53-m53evk.dts | 2 +-
arch/arm/boot/dts/imx53-mba53.dts | 2 +-
arch/arm/boot/dts/imx53-qsb.dts| 2 +-
arch/arm/boot/dts/imx53.dtsi | 122
+ - compatible : "cirrus,cs42l52"
+
+ - reg : the I2C address of the device for I2C
+
+Optional properties:
+
+ - reset-gpio : GPIO controller's phandle and the number
+of the GPIO used to reset the codec.
As Kumar has already mentioned, all device-specific properties should b
On Wed, 13 Nov 2013, Tomasz Figa wrote:
+0x00 through 0x0F.
+Frequency = (64xFs)/(N+2)
I suppose N means the value of chgfreq property here, but this should be
clearly stated. Same for Fs - I suppose it is sampling frequency, but
is it default, minimum, maximum
On Wed, Nov 13, 2013 at 10:29:07AM -0700, Stephen Warren wrote:
> It seems slightly odd to tightly link the drivers/of and
> drivers/regulator code like that, but I guess with the appropriate
> ifdefs it'll work out OK.
This isn't really regulator specific - it's something that applies in
general
Hi Brian,
On Wednesday 13 of November 2013 12:58:28 Brian Austin wrote:
> >> + - compatible : "cirrus,cs42l52"
> >> +
> >> + - reg : the I2C address of the device for I2C
> >> +
> >> +Optional properties:
> >> +
> >> + - reset-gpio : GPIO controller's phandle and the number
> >> + of
On 11/13/2013 2:23 AM, Denis Carikli wrote:
+ /* rgb666 */
+ ipu_dc_map_clear(priv, IPU_DC_MAP_RGB666);
+ ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 2, 17, 0xfc); /* red */
+ ipu_dc_map_config(priv, IPU_DC_MAP_RGB666, 1, 11, 0xfc); /* green */
+ ipu_dc_map_config(priv,
Hi Florian,
Seems like I accidentally replied to some old version of this patch.
Not sure how many of those comments were still relevant for V3, but
let me look at this version and see whether we can still improve things
a bit. Please see my comments inline.
On Wednesday 13 of November 2013 18:53
On Wed, Nov 13, 2013 at 6:34 PM, Rob Herring wrote:
>>> + if (!initial_boot_params ||
>>> + (be32_to_cpu(initial_boot_params->magic) != OF_DT_HEADER))
>>> + initial_boot_params = &__dtb_start;
>>> +
>>> /* check device tree validity */
>>> - if (be32_to_
On Wednesday 13 of November 2013 18:16:22 Mark Brown wrote:
> On Wed, Nov 13, 2013 at 05:47:07PM +0100, Tomasz Figa wrote:
> > On Wednesday 13 of November 2013 16:43:28 Mark Brown wrote:
>
> > > The best practice on this one seems to vary somewhat randomly -
> > > sometimes it's a requirement, som
On Wed, Nov 13, 2013 at 05:47:07PM +0100, Tomasz Figa wrote:
> On Wednesday 13 of November 2013 16:43:28 Mark Brown wrote:
> > The best practice on this one seems to vary somewhat randomly -
> > sometimes it's a requirement, sometimes it isn't.
> AFAIR we decided on ARM Mini Summit to mandate thi
On 11/13/2013 12:45 AM, Hiroshi Doyu wrote:
> On Wed, 13 Nov 2013 01:17:22 +0100
> Stephen Warren wrote:
>
>>> + mmu-masters = <&host1x TEGRA_SWGROUP_HC>,
>>> + <&mpe TEGRA_SWGROUP_MPE>,
>>> + <&vi TEGRA_SWGROUP_VI>,
>>> +
On Tue, Nov 12, 2013 at 6:14 PM, Alex Courbot wrote:
> On 11/13/2013 05:38 AM, Olof Johansson wrote:
>>
>> On Tue, Nov 12, 2013 at 12:26 PM, Stephen Warren
>> wrote:
>>>
>>> On 11/07/2013 03:11 AM, Alexandre Courbot wrote:
Just a set of small fixes to address the concerns expressed on v
On 11/13/2013 10:31 AM, Will Deacon wrote:
> On Wed, Nov 13, 2013 at 04:06:10PM +, Hiroshi Doyu wrote:
>> Will Deacon wrote @ Wed, 13 Nov 2013 15:38:04 +0100:
>>
>>> On Tue, Nov 12, 2013 at 11:34:20PM +, Stephen Warren wrote:
SMMU:
smmu: smmu@xx {
#smmu-cells
Add support for DMA controller of BCM2835 as used in the Raspberry Pi.
Currently it only supports cyclic DMA.
Signed-off-by: Florian Meier
---
Besides of many minor improvements (thanks to your helpful comments),
this fourth version does the assignment of the virtual to the hardware
channel alre
On 11/13/2013 12:23 AM, Hiroshi Doyu wrote:
> On Wed, 13 Nov 2013 00:34:20 +0100
> Stephen Warren wrote:
>
>> On 11/11/2013 01:31 AM, Hiroshi Doyu wrote:
>>> An "IOMMU device" on the bus is poplulated first, "IOMMU'able devices"
>>> are done later.
>>>
>>> With CONFIG_OF_IOMMU, "#stream-id-cells"
On 11/13/2013 07:38 AM, Will Deacon wrote:
> On Tue, Nov 12, 2013 at 11:34:20PM +, Stephen Warren wrote:
>> On 11/11/2013 01:31 AM, Hiroshi Doyu wrote:
>>> An "IOMMU device" on the bus is poplulated first, "IOMMU'able devices"
>>> are done later.
>>>
>>> With CONFIG_OF_IOMMU, "#stream-id-cells"
On 11/13/2013 11:20 AM, Geert Uytterhoeven wrote:
> On Wed, Nov 13, 2013 at 4:51 PM, Rob Herring wrote:
>> On Tue, Nov 12, 2013 at 1:42 PM, Geert Uytterhoeven
>> wrote:
>>> The different architectures used their own (and different) declarations:
>>>
>>> extern struct boot_param_header __dtb_s
On Wed, Nov 13, 2013 at 04:06:10PM +, Hiroshi Doyu wrote:
> Will Deacon wrote @ Wed, 13 Nov 2013 15:38:04 +0100:
>
> > On Tue, Nov 12, 2013 at 11:34:20PM +, Stephen Warren wrote:
> > > SMMU:
> > > smmu: smmu@xx {
> > > #smmu-cells = <1>;
> > > }
> > >
> > > Affected d
On 11/13/2013 05:23 AM, Mark Brown wrote:
> On Tue, Nov 12, 2013 at 11:20:44AM -0700, Stephen Warren wrote:
>
>> The only issue you may have to watch out for is: When is
>> regulator_init() called (i.e. when does core_initcall happen)
>> relative to when driver probe()s can be called? If it's ear
On Wed, Nov 13, 2013 at 4:51 PM, Rob Herring wrote:
> On Tue, Nov 12, 2013 at 1:42 PM, Geert Uytterhoeven
> wrote:
>> The different architectures used their own (and different) declarations:
>>
>> extern struct boot_param_header __dtb_start;
>> extern u32 __dtb_start[];
>> extern char
On Wed, Nov 13, 2013 at 01:33:52PM +0530, Viresh Kumar wrote:
> On 13 November 2013 00:31, Daniel Lezcano wrote:
> > Hmm, it could be interesting if Viresh can give its opinion on this patch
> > [cc'ed].
>
> I am not sure if I understood the problem completely, but if this is about
> not allowing
Hi Eduardo,
On Tuesday 12 of November 2013 15:46:04 Eduardo Valentin wrote:
> This patch introduces a device tree bindings for
> describing the hardware thermal behavior and limits.
> Also a parser to read and interpret the data and feed
> it in the thermal framework is presented.
[snip]
> diff --
On Wednesday 13 of November 2013 16:43:28 Mark Brown wrote:
> On Wed, Nov 13, 2013 at 05:33:30PM +0100, Tomasz Figa wrote:
> > On Wednesday 13 of November 2013 09:44:34 Brian Austin wrote:
>
> > > + - reset-gpio : GPIO controller's phandle and the number
> > > + of the GPIO used to reset
On Wed, Nov 13, 2013 at 05:33:30PM +0100, Tomasz Figa wrote:
> On Wednesday 13 of November 2013 09:44:34 Brian Austin wrote:
> > + - reset-gpio : GPIO controller's phandle and the number
> > +of the GPIO used to reset the codec.
> As Kumar has already mentioned, all device-specific p
On Wed, Nov 13, 2013 at 08:01:01PM +0530, Vinod Koul wrote:
> On Wed, Nov 13, 2013 at 02:54:41PM +, Mark Brown wrote:
> > Yes, though I think some of the stuff Martin was talking about will need
> > changes to the dmaengine APIs. He was wanting to reuse DMA lists which
> > currently dmaengine
Hi Brian,
On Wednesday 13 of November 2013 09:44:34 Brian Austin wrote:
> Add Device Tree Binding for the CS42L52 Codec
>
> v2 Adds clearer explaination of mic configs and select.
> Renames bindings to '-' instead of '_'.
> Definition of GPIO for reset pin.
>
> Signed-off-by: Brian Austin
> ---
+Required properties:
+
+ - compatible : "cirrus,cs42l52"
+
+ - reg : the I2C address of the device for I2C
+
+Optional properties:
+
+ - reset-gpio : GPIO controller's phandle and the number
+of the GPIO used to reset the codec.
+ - chgfreq: Charge Pump Frequency values. A
On 11/13/2013 07:40 AM, Michal Simek wrote:
> On 11/13/2013 11:19 AM, Michal Simek wrote:
>> On 11/12/2013 08:42 PM, Geert Uytterhoeven wrote:
>>> Kill the microblaze-specific __fdt_blob section, and start
>>> using .dtb.init.rodata from for
>>> built-in DTBs, like most other DT enabled architectu
On Wednesday 13 November 2013 10:32 AM, Nishanth Menon wrote:
> On 11/11/2013 11:47 PM, Sricharan R wrote:
[..]
>
> Rationale - with more TI SoCs trending towards crossbar, we dont need
> to keep adding to the soc_is checks, further, we intend to remove
> soc_is checks in it's entirety..
>
Just
Will Deacon wrote @ Wed, 13 Nov 2013 15:38:04 +0100:
> On Tue, Nov 12, 2013 at 11:34:20PM +, Stephen Warren wrote:
> > On 11/11/2013 01:31 AM, Hiroshi Doyu wrote:
> > > An "IOMMU device" on the bus is poplulated first, "IOMMU'able devices"
> > > are done later.
> > >
> > > With CONFIG_OF_IOM
On Nov 13, 2013, at 9:44 AM, Brian Austin wrote:
> Add Device Tree Binding for the CS42L52 Codec
>
> v2 Adds clearer explaination of mic configs and select.
> Renames bindings to '-' instead of '_'.
> Definition of GPIO for reset pin.
>
> Signed-off-by: Brian Austin
> ---
> .../devicetree/bin
On Tue, Nov 12, 2013 at 1:42 PM, Geert Uytterhoeven
wrote:
> The different architectures used their own (and different) declarations:
>
> extern struct boot_param_header __dtb_start;
> extern u32 __dtb_start[];
> extern char __dtb_start[];
>
> Consolidate them using the first variant i
This patch adds device tree support for the CS42L52 CODEC
v2 changes dt bindings to use '-' instead of '_'.
reset_gpio = reset-gpio. Pdata variables are not changed.
Signed-off-by: Brian Austin
---
sound/soc/codecs/cs42l52.c | 51 --
1 file changed, 4
Add Device Tree Binding for the CS42L52 Codec
v2 Adds clearer explaination of mic configs and select.
Renames bindings to '-' instead of '_'.
Definition of GPIO for reset pin.
Signed-off-by: Brian Austin
---
.../devicetree/bindings/sound/cs42l52.txt | 48 ++
1 file
On Wednesday 13 November 2013 09:02 PM, Nishanth Menon wrote:
> On 11/11/2013 11:47 PM, Sricharan R wrote:
>> Hi Rajendra,
>>
>> On Tuesday 12 November 2013 11:11 AM, Rajendra Nayak wrote:
>>> On Tuesday 05 November 2013 06:44 PM, Sricharan R wrote:
Enable the crossbar IP support for DRA7xx so
Hi,
On Wednesday 13 November 2013 08:54 PM, Santosh Shilimkar wrote:
> On Tuesday 05 November 2013 08:14 AM, Sricharan R wrote:
>> In some socs the gic can be preceded by a crossbar IP which
>> routes the peripheral interrupts to the gic inputs. The peripheral
>> interrupts are associated with a fi
On 11/11/2013 11:47 PM, Sricharan R wrote:
> Hi Rajendra,
>
> On Tuesday 12 November 2013 11:11 AM, Rajendra Nayak wrote:
>> On Tuesday 05 November 2013 06:44 PM, Sricharan R wrote:
>>> Enable the crossbar IP support for DRA7xx soc.
>>>
>>> Cc: Santosh Shilimkar
>>> Cc: Rajendra Nayak
>>> Cc: To
On Tuesday 05 November 2013 08:14 AM, Sricharan R wrote:
> The wakeup gen mask/unmask callback uses the irq element of the
> irq_data to setup. The irq is the linux virtual irq number and
> is same as the hardware irq number only when the parent irqchip
> is setup as a legacy domain. When it is use
On Tuesday 05 November 2013 08:14 AM, Sricharan R wrote:
> Enable the crossbar IP support for DRA7xx soc.
>
> Cc: Santosh Shilimkar
> Cc: Rajendra Nayak
> Cc: Tony Lindgren
> Signed-off-by: Sricharan R
> ---
Acked-by: Santosh Shilimkar
--
To unsubscribe from this list: send the line "unsubsc
On Tuesday 05 November 2013 08:14 AM, Sricharan R wrote:
> There is a IRQ crossbar device in the soc, which maps the
> irq requests from the peripherals to the mpu interrupt
> controller's inputs. The gic provides the support for such
> IPs in the form of routable-irqs. So adding the property
> her
On Tuesday 05 November 2013 08:14 AM, Sricharan R wrote:
> Now with the crossbar IP in picture, the peripherals do not have the
> fixed interrupt lines. Instead they rely on the crossbar irqchip to
> allocate and map a free interrupt line to its crossbar input. So replacing
> all the peripheral int
On Tuesday 05 November 2013 08:14 AM, Sricharan R wrote:
> This adds the irq crossbar device node.
>
> There is a IRQ crossbar device in the soc, which
> maps the irq requests from the peripherals to the
> mpu interrupt controller's inputs. The Peripheral irq
> requests are connected to only one c
On Tuesday 05 November 2013 08:14 AM, Sricharan R wrote:
> Some socs have a large number of interrupts requests to service
> the needs of its many peripherals and subsystems. All of the
> interrupt lines from the subsystems are not needed at the same
> time, so they have to be muxed to the irq-cont
On Wed, Nov 13, 2013 at 02:54:41PM +, Mark Brown wrote:
> On Wed, Nov 13, 2013 at 07:05:36PM +0530, Vinod Koul wrote:
> > On Wed, Nov 13, 2013 at 12:51:11PM +, Mark Brown wrote:
>
> > > I'm probably going to be looking at that at some point, though perhaps
> > > Martin will get to it since
On Tue, Nov 12, 2013 at 12:24:15PM +0100, Denis Carikli wrote:
> --- /dev/null
> +++ b/arch/arm/mach-imx/imx35-dt.c
> @@ -0,0 +1,48 @@
> +/*
> + * Copyright 2012 Steffen Trumtrar, Pengutronix
> + *
> + * based on imx27-dt.c
> + *
> + * This program is free software; you can redistribute it and/or m
On Tuesday 05 November 2013 08:14 AM, Sricharan R wrote:
> In some socs the gic can be preceded by a crossbar IP which
> routes the peripheral interrupts to the gic inputs. The peripheral
> interrupts are associated with a fixed crossbar input line and the
> crossbar routes that to one of the free
On Tue, Nov 12, 2013 at 12:24:18PM +0100, Denis Carikli wrote:
> The following devices/functionalities were added:
> * Main and secondary UARTs.
> * i2c and the pcf8563 device.
> * Ethernet.
> * NAND.
> * The BP1 button.
> * The LED.
> * Watchdog
> * SD.
>
> Cc: Rob Herring
> Cc: Pawel Mo
On 13/11/13 14:38, Tomasz Figa wrote:
> On Wednesday 13 of November 2013 14:31:25 James Hogan wrote:
>> On 13/11/13 14:18, Tomasz Figa wrote:
>>> Hi James, Mike,
>>>
>>> On Wednesday 13 of November 2013 14:09:56 James Hogan wrote:
On 29/05/13 18:39, Mike Turquette wrote:
> Quoting James Ho
On Tue, Nov 12, 2013 at 12:24:17PM +0100, Denis Carikli wrote:
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx35.dtsi
> @@ -0,0 +1,312 @@
> +/*
> + * Copyright 2012 Steffen Trumtrar, Pengutronix
> + *
> + * based on imx27.dtsi
> + *
> + * This program is free software; you can redistribute it and/or
On Wed, Nov 06, 2013 at 10:16:13AM +, Lee Jones wrote:
> This is used for MSP (audio) devices which is about to be fully DT:ed.
>
> Cc: devicetree@vger.kernel.org
> Cc: Vinod Koul
> Signed-off-by: Lee Jones
Acked-by: Vinod Koul
--
~Vinod
> ---
> Documentation/devicetree/bindings/dma/ste-d
On Wed, Nov 13, 2013 at 10:41:41PM +0800, Shawn Guo wrote:
> On Tue, Nov 12, 2013 at 09:50:06AM +0100, Markus Pargmann wrote:
> > Pinctrl driver node and pin group definitions for other driver nodes.
>
> Neither patch subject nor commit log is telling anything useful, like
> what is the change and
Hi Florian,
Most of technical issues have been already mentioned by Russell, but let
me also point those that I found. Please see my comments inline.
On Friday 08 of November 2013 18:22:34 Florian Meier wrote:
> Add support for DMA controller of BCM2835 as used in the Raspberry Pi.
> Currently it
Use dual-fifo sdma scripts instead of shared scripts for ssi on i.MX series.
Signed-off-by: Nicolin Chen
Acked-by: Shawn Guo
---
arch/arm/boot/dts/imx51.dtsi | 4 ++--
arch/arm/boot/dts/imx53.dtsi | 4 ++--
arch/arm/boot/dts/imx6qdl.dtsi | 12 ++--
arch/arm/boot/dts/imx6sl.dtsi |
This patch adds a new DMA_TYPE for SSI dual FIFO script, included
in SDMA firmware version 2. This script would allow SSI use dual
fifo mode to transimit/receive data without occasional hardware
underrun/overrun.
Signed-off-by: Nicolin Chen
Acked-by: Kumar Gala
Acked-by: Sascha Hauer
---
Docum
On Wed, Nov 13, 2013 at 07:05:36PM +0530, Vinod Koul wrote:
> On Wed, Nov 13, 2013 at 12:51:11PM +, Mark Brown wrote:
> > I'm probably going to be looking at that at some point, though perhaps
> > Martin will get to it since he seems to be looking at this.
> Okay sounds good. This will also h
By enabling dual fifo mode, it would allow SSI enter a better performance
to transimit/receive data without occasional hardware underrun/overrun.
Signed-off-by: Nicolin Chen
Acked-by: Timur Tabi
Acked-by: Mark Brown
---
sound/soc/fsl/fsl_ssi.c | 27 ++-
1 file changed,
On i.MX5/6 series, SDMA is using new version firmware to support SSI
dual FIFO feature and HDMI Audio (i.MX6Q/DL only). Thus add it.
Signed-off-by: Nicolin Chen
Acked-by: Sascha Hauer
---
drivers/dma/imx-sdma.c | 15 ++-
include/linux/platform_data/dma-imx-sdma.h
* ! This series of patches has a direct dependency between them. When
* ! applying them, we need to apply to one single branch. Otherwise,
* ! it would break currect branches.
Changelog
v7:
* Appended missing Acked-by to all four patches.
* Sorry that I didn't add them at the first place.
v6:
On 13-11-2013 05:42, Mark Rutland wrote:
> Hi,
>
> On Tue, Nov 12, 2013 at 08:14:41PM +, Eduardo Valentin wrote:
>> On 12-11-2013 15:59, Olof Johansson wrote:
>>> On Tue, Nov 12, 2013 at 11:46 AM, Eduardo Valentin
>>> wrote:
After discussion and agreement of thermal device tree bindings,
On Tue, Nov 12, 2013 at 09:50:06AM +0100, Markus Pargmann wrote:
> Pinctrl driver node and pin group definitions for other driver nodes.
Neither patch subject nor commit log is telling anything useful, like
what is the change and why the changes.
Shawn
>
> Signed-off-by: Markus Pargmann
> ---
On Wednesday 13 of November 2013 14:31:25 James Hogan wrote:
> On 13/11/13 14:18, Tomasz Figa wrote:
> > Hi James, Mike,
> >
> > On Wednesday 13 of November 2013 14:09:56 James Hogan wrote:
> >> On 29/05/13 18:39, Mike Turquette wrote:
> >>> Quoting James Hogan (2013-05-10 05:44:22)
> The fre
On Tue, Nov 12, 2013 at 11:34:20PM +, Stephen Warren wrote:
> On 11/11/2013 01:31 AM, Hiroshi Doyu wrote:
> > An "IOMMU device" on the bus is poplulated first, "IOMMU'able devices"
> > are done later.
> >
> > With CONFIG_OF_IOMMU, "#stream-id-cells" DT binding would be used to
> > identify whe
On Tue, Nov 12, 2013 at 09:50:03AM +0100, Markus Pargmann wrote:
> Hi,
>
> This series contains only DTS changes for imx27-pinctrl. It depends on the
> incremental driver patch which allows iomux subdevices [1].
Applied patches #1, #2 and #7.
Unless LinusW create a topic branch for that dependen
1 - 100 of 163 matches
Mail list logo
