On Thu, Jul 18, 2013 at 10:20:52PM +0200, Gerhard Sittig wrote:
> + /* enable clock for the I2C peripheral (non fatal) */
> + clk = of_clk_get_by_name(node, "per");
> + if (!IS_ERR(clk)) {
> + clk_prepare_enable(clk);
> + clk_put(clk);
> + }
> +
This kind of
On Thu, Jul 18, 2013 at 11:46:39AM -0500, Joel Fernandes wrote:
> The API is optionally implemented by dmaengine drivers and when
> unimplemented will return a NULL pointer. A client driver using
> this API provides the required dma channel, address width, and
> burst size of the transfer. dma_get_
On Thu, Jul 18, 2013 at 09:04:02AM +0200, Gerhard Sittig wrote:
> The common clock API assumes (it's part of the contract) that
> there are potentially expensive operations like get, put, prepare
> and unprepare, as well as swift and non-blocking operations like
> enable and disable.
Let's get som
On Wed, Jul 17, 2013 at 11:57:55AM -0400, Nicolas Pitre wrote:
> The sanest location at this point might simply be
> drivers/platform/vexpress_spc.c or drivers/platform/vexpress/spc.c
> depending on whether or not more such driver glue is expected in the
> vexpress future. No point putting "arm
On Sun, Jul 14, 2013 at 12:16:58AM +0200, Sylwester Nawrocki wrote:
> On 07/13/2013 11:02 PM, Russell King - ARM Linux wrote:
>> On Sat, Jul 13, 2013 at 10:43:29PM +0200, Sylwester Nawrocki wrote:
>>> I wasn't aware of it, thanks. I've seen a patch from Jiada Wang, it
On Sat, Jul 13, 2013 at 10:43:29PM +0200, Sylwester Nawrocki wrote:
> I wasn't aware of it, thanks. I've seen a patch from Jiada Wang, it seems
> they're working on v4 with clock object reference counting. Presumably we
> need both clk_get() to be taking reference on the module and reference
> coun
On Sat, Jul 13, 2013 at 07:44:58PM +0200, Sebastian Hesselbarth wrote:
> On 07/13/2013 01:12 PM, Russell King - ARM Linux wrote:
>> When I designed the clk API, I arranged for things like clk_get() to
>> take a reference on the module if the clock was supplied by a module.
>
On Sat, Jul 13, 2013 at 08:25:15AM -0600, Daniel Drake wrote:
> I guess the IRE falls into the same category as the DCON - we won't
> implement it for now, but knowing where it might fit in is useful.
I don't see much need at the moment for IRE. IRE isn't going to be
useful for general graphics r
On Sat, Jul 13, 2013 at 12:56:50PM +0200, Sylwester Nawrocki wrote:
> On 07/13/2013 10:35 AM, Jean-Francois Moine wrote:
>> On Fri, 12 Jul 2013 13:00:23 -0600 Daniel Drake wrote:
>>> On Fri, Jul 12, 2013 at 12:39 PM, Jean-Francois Moine
>>> wrote:
>
- the phandles to the clocks does not tel
On Fri, Jul 12, 2013 at 01:58:35PM -0600, Stephen Warren wrote:
> Is there a (possibly just proposed) mechanism in place to allow *.dts
> from multiple Linux architectures to share common *.dtsi files?
Don't forget that the long term goal is to move these files out of the
kernel source, which mean
On Mon, Jul 08, 2013 at 06:03:57PM +0800, Ming Lei wrote:
> On Sat, Jul 6, 2013 at 5:15 PM, Russell King - ARM Linux
> wrote:
> > On Sat, Jul 06, 2013 at 10:21:05AM +0800, Ming Lei wrote:
> >> But please see below words in Documentation/DMA-API.txt:
> >>
> &g
On Fri, Jul 05, 2013 at 12:33:21PM -0700, Laura Abbott wrote:
> On 7/3/2013 7:15 AM, Ming Lei wrote:
>> On Sat, Apr 27, 2013 at 5:32 AM, Rob Herring wrote:
>>> On 04/26/2013 03:31 PM, Laura Abbott wrote:
Currently, of_platform_device_create_pdata always sets the
coherent DMA mask to 32 b
On Sat, Jul 06, 2013 at 10:21:05AM +0800, Ming Lei wrote:
> But please see below words in Documentation/DMA-API.txt:
>
>Further, the physical address of the memory must be within the
>dma_mask of the device (the dma_mask represents a bit mask of the
>addressable
On Wed, Jul 03, 2013 at 10:15:50PM +0800, Ming Lei wrote:
>
> Without the patch, LPAE enabled board may not boot at all, but looks
> it still isn't in -next tree.
>
> But I am wondering if it is a correct approach, because enabling LPAE
> doesn't mean the I/O devices can support DMA to/from 64bit
s to register their devices OF node plus "shared" data
so that other drivers can find it. "shared" data might be a
standardized operations struct or something similar to 'struct
device_driver' but for componentised devices.
--
Russell King
_
On Thu, Jul 04, 2013 at 10:58:17AM +0200, Sascha Hauer wrote:
> On Thu, Jul 04, 2013 at 09:40:52AM +0100, Russell King wrote:
> > Wrong. Please read the example with the diagrams I gave. Consider
> > what happens if you have two display devices connected to a single
> > ou
unteering? :)
I don't think that Sebastian nor myself have either the motivation nor
the time available to go down that route of majorly rewriting kernel
subsystems.
Not only that but I believe it to be an unsafe approach as I've already
outlined.
--
Russell King
__
On Thu, Jul 04, 2013 at 10:33:07AM +0200, Sascha Hauer wrote:
> On Wed, Jul 03, 2013 at 10:52:49AM +0100, Russell King wrote:
> > > > Sorry but I'd like to say that this cannot be used commonly. Shouldn't
> > > > you
> > > > really consider Linu
of details, and we've firmly decided that this is
the wrong approach.
Today, there is a very strong push towards having a single kernel image
which runs on every (modern) ARM board with DT describing not only the
board level hardware but also the internal SoC as well.
--
Russell King
__
t
the LCD panel because the driver doesn't know that there's a LCD panel
also connected? This is why I feel that the hotplug idea is actually
rather unsafe, and if we go down that path we're building in that risk.
(And I think the OLPC guys may be have exactly that kind of set
em which we're
having with DRM.
--
Russell King
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
ot "describing the
hardware" to put into DT that LCD0, DCON, and the HDMI transceiver are
all connected together and therefore are required? One of the points of
DT after all is that it can and should be used to represent the
relationship between devices.
No - using the tree approach
part.)
Such a thing could be turned into a generic solution for all the
multi-part drivers. If we use Sebastian's idea of using phandles
(it seems there's a precident for it with the direction v4l2 is
going to solve a similar problem) then we likely have a standard
way of describing c
o we have enough people
with sufficient knowledge and willingness to be able to make all
that happen? I don't think we do, and I don't see that there's any
funding out there to make such a project happen, which would make it
a volunteer/spare time effort.
--
Russell King
_
ices.
I'm actually starting to come towards the conclusion that we should go
for the easiest solution, which is the one I just mentioned, and forget
trying to combine these devices into one super DRM driver.
--
Russell King
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
On Tue, Jul 02, 2013 at 12:54:41PM -0600, Daniel Drake wrote:
> On Tue, Jul 2, 2013 at 12:43 PM, Russell King wrote:
> > I will point out that relying on driver probing orders has already been
> > stated by driver model people to be unsafe. This is why I will not
> > adopt s
model people to be unsafe. This is why I will not
adopt such a solution for my driver; it is a bad design.
--
Russell King
___
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
On Thu, Jun 27, 2013 at 09:17:13AM +0300, Felipe Balbi wrote:
> On Wed, Jun 26, 2013 at 05:00:34PM +0200, Sylwester Nawrocki wrote:
> > Hi,
> >
> > On 06/25/2013 05:06 PM, Felipe Balbi wrote:
> > >> +static struct platform_driver exynos_video_phy_driver = {
> > >> > + .probe = exynos_video_p
On Tue, Jun 18, 2013 at 05:02:49PM +0200, Linus Walleij wrote:
> Nowadays I would do the above with regmap_update_bits().
>
> Mutual exclusion for read-modify-write of individual bits in a
> register is one of those cases where doing a regmap over
> a memory-mapped register range makes a lot of se
On Thu, Sep 13, 2012 at 05:41:44PM +0200, Sebastian Hesselbarth wrote:
> +#define DOVE_GLOBAL_CONFIG_1 (DOVE_SB_REGS_VIRT_BASE | 0xe802C)
> +#define DOVE_TWSI_ENABLE_OPTION1BIT(7)
> +#define DOVE_GLOBAL_CONFIG_2 (DOVE_SB_REGS_VIRT_BASE | 0xe8030)
> +#define DOVE_TWSI_ENABLE_OP
On Tue, Jun 11, 2013 at 07:50:31AM +0100, Srinivas KANDAGATLA wrote:
> You are right, It does not make sense to use BIT() macro for field which
> has more than 1 bit. I think using mix of both BIT() and the old style
> will make code look bit confusing to reader, Also no other mach code in
> the ke
On Mon, Jun 10, 2013 at 12:46:59PM +0100, Srinivas KANDAGATLA wrote:
> > + aux_ctrl = (0x1 << L2X0_AUX_CTRL_SHARE_OVERRIDE_SHIFT) |
> > + (0x1 << L2X0_AUX_CTRL_DATA_PREFETCH_SHIFT) |
> > + (0x1 << L2X0_AUX_CTRL_INSTR_PREFETCH_SHIFT) |
> > +
On Mon, Jun 10, 2013 at 10:21:00AM +0100, Srinivas KANDAGATLA wrote:
> This patch adds support to ASC (asynchronous serial controller)
> driver, which is basically a standard serial driver. This IP is common
> across all the ST parts for settop box platforms.
>
> ASC is embedded in ST COMMS IP blo
On Mon, Jun 10, 2013 at 05:11:15PM +0900, Alexandre Courbot wrote:
> On Sat, Jun 8, 2013 at 1:33 AM, Stephen Warren wrote:
> >>> I think we need to separate the concept of support for *a* secure
> >>> monitor, from support for a *particular* secure monitor.
> >>
> >> Agreed. In this case, can we a
On Mon, Jun 10, 2013 at 04:47:22PM +0900, Alexandre Courbot wrote:
> One could remove the naked attribute and put there registers into the
> clobber list, but then the function will be inlined and we will have
> to ensure the parameters end up in the right register (and having a
> function that can
On Sun, Jun 09, 2013 at 11:09:59PM +0100, luke.leighton wrote:
> this is all a rather round-about way to say that for those people who
> heard and are thinking of heeding russell's call to "be silent and to
> ignore me"
Okay, so you've just misrepresented me in the above comment. I never
said any
On Fri, Jun 07, 2013 at 08:18:14PM +0100, Luke Kenneth Casson Leighton wrote:
> On Fri, Jun 7, 2013 at 7:26 PM, Russell King - ARM Linux
> wrote:
> > Luke Leighton on the other hand is demanding that we
>
> no demands have been made, russell: i've informed you of an imm
On Fri, Jun 07, 2013 at 08:04:26PM +0100, luke.leighton wrote:
> On Fri, Jun 7, 2013 at 7:54 PM, Olof Johansson wrote:
> > By demanding
>
> a-a-ah, no demands made.
" well, tough. get me up to speed, *fast*. please stop wasting time
like this: get me up to speed."
That is a demand. Stop tro
On Fri, Jun 07, 2013 at 08:02:03PM +0100, luke.leighton wrote:
> well, tough. get me up to speed, *fast*.
No, not unless you're willing to *pay* someone to spend time teaching you,
because you are asking to be *taught* about the current situation, so
you're asking someone to do some _work_ _for_
On Fri, Jun 07, 2013 at 02:49:28PM +, joem wrote:
> > > SoC vendors are free to join the discussion, and many SoC vendors are part
> > > of the kernel community, so calling this unilateral is plain wrong.
> >
> > you're free to believe that, vladimir. i've explained why that
> > hasn't happe
On Fri, Jun 07, 2013 at 09:48:22AM +0200, Vladimir Pantelic wrote:
> luke.leighton wrote:
>> 3 days remaining on the clock.
>
> what catastrophic thing will happen when the time runs out?
Maybe the world will explode into tiny small bits? Probably not. I
suspect nothing of any relevance to us.
On Fri, Jun 07, 2013 at 10:40:37AM +0200, Vladimir Pantelic wrote:
> luke.leighton wrote:> so.
> >
> > coming back to what you said earlier: i'm formulating what to say to
> > allwinner [and need to pre-send something by monday so that they can
> > consider it before the meeting]. so far, it c
On Fri, Jun 07, 2013 at 09:02:43AM +0100, luke.leighton wrote:
> ok. so. we come back to the question again: what shall i propose to
> them that they consider doing, and what benefit would it be to them to
> do so?
>
> i cannot go to them and say "you have to do this [insert proposal
> here]"
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 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 prefer to play safe here and explicitly move
> + * th
On Wed, Jun 05, 2013 at 05:38:45PM -0400, Lennart Sorensen wrote:
> I haven't personally dealt with any nvidia arm devices, so I have no
> idea how those are turning out, nor have I looked much at the marvell
> ones yet (even though I have a cubox sitting on my desk I intend to play
> around with).
On Wed, Jun 05, 2013 at 03:00:13PM -0600, Stephen Warren wrote:
> 2) Having U-Boot itself read a DT and configure itself, just like the
> kernel does. This is relatively new, and only supported by a few boards
> (all Tegra to some extent, and a couple each Samsung Exynos and Xilinx
> boards). I sus
On Mon, Jun 03, 2013 at 05:19:44PM -0700, Rohit Vaswani wrote:
> + sc1_base_ptr = of_iomap(dn, 0);
> + if (sc1_base_ptr) {
> + writel_relaxed(0, sc1_base_ptr + VDD_SC1_ARRAY_CLAMP_GFS_CTL);
> + writel_relaxed(0, sc1_base_ptr + SCSS_CPU1CORE_RESET);
> + wr
On Fri, May 24, 2013 at 01:01:25PM -0400, Jason Cooper wrote:
> On Fri, May 24, 2013 at 01:03:25PM +0200, Linus Walleij wrote:
> > IMO: if you want to go down that road, what you really want is not
> > ever more expressible device trees, but real open firmware,
> > or ACPI or UEFI that can interpre
On Thu, May 23, 2013 at 04:16:13PM +0800, Huang Shijie wrote:
> + /* get the clock */
> + weim->clk = devm_clk_get(&pdev->dev, NULL);
> + if (IS_ERR(weim->clk))
> + goto weim_err;
> +
> + clk_prepare_enable(weim->clk);
I notice people are getting lazy about this. clk_p
On Wed, May 08, 2013 at 09:36:13AM -0700, Greg KH wrote:
> On Wed, May 08, 2013 at 06:31:48PM +0200, Arnd Bergmann wrote:
> > On Wednesday 08 May 2013, Greg KH wrote:
> > > > just mention there is not hardware reason to not use the generic ttySx
> > > > in place of ttyAS as we have only one IP that
On Thu, May 09, 2013 at 01:44:34PM -0700, Olof Johansson wrote:
> On Thu, May 02, 2013 at 05:57:33PM -0700, Christian Daudt wrote:
> > Rev A2 SoCs have an unorthodox memory re-mapping and this needs
> > to be reflected in the cache operations.
> > This patch adds new outer cache functions for the l
On Fri, May 03, 2013 at 09:50:50PM -, Thomas Gleixner wrote:
> - u32 mask = ~(1 << (d->irq - gc->irq_base));
> + u32 mask = ~(d->mask);
I suspect the above changes are all a result of a search-and-replace
which results in the cosmetic parens remaining. Would be nice to get
rid of them
On Fri, May 03, 2013 at 09:50:53PM -, Thomas Gleixner wrote:
> + /* Init mask cache ? */
> + if (dgc->gc_flags & IRQ_GC_INIT_MASK_CACHE) {
> + raw_spin_lock_irqsave(&gc->lock, flags);
> + gc->mask_cache = irq_reg_readl(gc->reg_base + ct->regs.mask);
> +
On Fri, May 03, 2013 at 01:48:35AM +0200, Sebastian Hesselbarth wrote:
> 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: Se
On Thu, May 02, 2013 at 08:54:20PM +0200, Sebastian Hesselbarth wrote:
> On 05/02/13 20:45, Russell King - ARM Linux wrote:
>> On Thu, May 02, 2013 at 08:33:48PM +0200, Sebastian Hesselbarth wrote:
>>> On 05/02/2013 08:25 PM, Sebastian Hesselbarth wrote:
>>>> This pa
On Thu, May 02, 2013 at 08:33:48PM +0200, Sebastian Hesselbarth wrote:
> On 05/02/2013 08:25 PM, Sebastian Hesselbarth wrote:
>> This patch adds an irqchip driver for the main interrupt controller found
>> on Marvell Orion SoCs (Kirkwood, Dove, Orion5x, Discovery Innovation).
>> Corresponding devic
On Fri, Apr 26, 2013 at 12:19:08PM +0200, Fabio Baltieri wrote:
> On Thu, Apr 25, 2013 at 06:46:35PM +0100, Russell King wrote:
> > On Thu, Apr 25, 2013 at 10:13:34AM -0400, Eduardo Valentin wrote:
> > > diff --git a/drivers/thermal/db8500_cpufreq_cooling.c
>
On Thu, Apr 25, 2013 at 10:09:57AM -0700, Laura Abbott wrote:
> I thought about this as well but in arch/arm/mm/mm.h:
>
> #ifdef CONFIG_ZONE_DMA
> extern phys_addr_t arm_dma_limit;
> #else
> #define arm_dma_limit ((phys_addr_t)~0)
> #endif
>
> arm_dma_limit is explicitly cast to phys_addr_t, which
t; dev_err(&pdev->dev, "Failed to register cooling device\n");
> return PTR_ERR(cdev);
Correct. cpufreq_cooling_register() returns either an error-pointer or
a valid pointer.
--
Russell King
Linux kern
On Thu, Apr 25, 2013 at 03:31:07PM +0400, Alexander Shiyan wrote:
> > On Sat, Apr 13, 2013 at 08:21:39AM +0400, Alexander Shiyan wrote:
> > > +static void __init clps711x_add_gpio(void)
> > > +{
> > > + const struct resource clps711x_gpio0_res[] = {
> > > + DEFINE_RES_MEM(PADR, SZ_1),
> > >
On Thu, Apr 18, 2013 at 06:33:21PM +0100, Pawel Moll wrote:
> This patch adds basic DT bindings for the PL11x CLCD cells
> and make their fbdev driver use them, together with the
> Common Display Framework.
>
> The DT provides information about the hardware configuration
> and limitations (eg. the
On Thu, Apr 18, 2013 at 01:54:04PM -0400, Nicolas Pitre wrote:
> On Thu, 18 Apr 2013, Stephen Boyd wrote:
>
> > On 04/11/13 07:47, Lorenzo Pieralisi wrote:
> > > diff --git a/drivers/bus/arm-cci.c b/drivers/bus/arm-cci.c
> > > new file mode 100644
> > > index 000..81953de
> > > --- /dev/null
>
On Mon, Apr 15, 2013 at 12:36:09PM -0400, Jason Cooper wrote:
> Russell,
>
> Thanks for applying this patch (7683/1) to your tree. I see it's in
> your for-next, which I understand *isn't* stable.
That is correct.
> 029baf1 ARM: 7683/1: pci: add a align_resource hook
>
> Is there a stable br
On Sat, Apr 13, 2013 at 08:21:39AM +0400, Alexander Shiyan wrote:
> +static void __init clps711x_add_gpio(void)
> +{
> + const struct resource clps711x_gpio0_res[] = {
> + DEFINE_RES_MEM(PADR, SZ_1),
> + DEFINE_RES_MEM(PADDR, SZ_1),
> + };
> + const struct resour
On Wed, Apr 17, 2013 at 04:17:18PM +0100, Pawel Moll wrote:
> +#if defined(CONFIG_OF)
> +static int clcdfb_of_get_tft_parallel_panel(struct clcd_panel *panel,
> + struct display_entity_interface_params *params)
> +{
> + int r = params->p.tft_parallel.r_bits;
> + int g = params->
On Sat, Mar 23, 2013 at 01:04:53PM +0900, Jingoo Han wrote:
> - switch ((pci_space >> 24) & 0x3) {
> - case 1: /* PCI IO space */
> + if (iter.flags & IORESOURCE_IO) {
Please look at how IORESOURCE_* stuff is defined:
#define IORESOURCE_TYPE_BITS0x00
On Thu, Mar 21, 2013 at 09:31:01PM -0500, Rob Herring wrote:
> Perhaps re-writing it like this would be more clear:
>
> if (irq_num == 2){
> __sp804_clockevents_init(base + TIMER_2_BASE, irq, clk1, name);
> __sp804_clocksource_and_sched_clock_init(base, name, clk0, 1);
> } else {
>
On Thu, Mar 21, 2013 at 05:26:15PM +0100, Gregory CLEMENT wrote:
> From: Lior Amsalem
>
> For mvebu IOs are 32 bits and we have 40 bits memory due to LPAE so
> make sure we give 32 bits addresses to the IOs.
>
> Signed-off-by: Lior Amsalem
> Tested-by: Franklin
> Signed-off-by: Gregory CLEMENT
On Wed, Mar 20, 2013 at 05:54:11PM -0500, Rob Herring wrote:
> +Optional properties:
> +- arm,sp804-has-irq = <#>: In the case of only 1 timer irq line connected,
> this
> + specifies if the irq connection is for timer 1 or timer 2. A value of 1
> + or 2 should be used.
This fails to ment
On Wed, Mar 20, 2013 at 05:54:02PM -0500, Rob Herring wrote:
> From: Rob Herring
>
> The timer-sp initialization code clears the control register before
> initializing the timers, so every platform doing this is redundant.
>
> For unused timers, we should not care what state they are in.
NAK.
On Wed, Mar 20, 2013 at 05:54:03PM -0500, Rob Herring wrote:
> + clk0 = of_clk_get(np, 0);
> + if (IS_ERR(clk0))
> + clk0 = NULL;
> +
> + /* Get the 2nd clock if the timer has 2 timer clocks */
> + if (of_count_phandle_with_args(np, "clocks", "#clock-cells") == 3) {
> +
On Thu, Mar 14, 2013 at 07:08:34PM +0100, Florian Fainelli wrote:
> + if (dev->err_interrupt == NO_IRQ) {
...
> + init_waitqueue_head(&dev->smi_busy_wait);
> +
> + dev->err_interrupt = platform_get_irq(pdev, 0);
> + if (dev->err_interrupt != -ENXIO) {
...
> + } else
> +
On Sun, Mar 10, 2013 at 06:18:22PM +0100, Javier Martinez Canillas wrote:
> +static int gpmc_probe_ethernet_child(struct platform_device *pdev,
> + struct device_node *child)
> +{
> + int ret, cs;
> + unsigned long base;
> + struct resource res;
> +
On Fri, Mar 01, 2013 at 04:41:37PM -0600, Jon Hunter wrote:
> Thanks for the history. For OMAP I see SMC_IRQ_FLAGS getting defined as
> follows in smc91x.h ...
>
> #ifndef SMC_IRQ_FLAGS
> #define SMC_IRQ_FLAGS IRQF_TRIGGER_RISING
> #endif
>
> And so for OMAP devices using smc91x, it is
On Fri, Mar 01, 2013 at 05:17:57PM +0100, Javier Martinez Canillas wrote:
> >> unsigned long irq_flags = SMC_IRQ_FLAGS;
> >> ...
> >>if (irq_flags == -1 || ires->flags & IRQF_TRIGGER_MASK)
> >> irq_flags = ires->flags & IRQF_TRIGGER_MASK;
> >>
> >> while smsc911x driver's pr
On Mon, Feb 18, 2013 at 07:30:29PM +0800, Wei Ni wrote:
> +static struct tegra_thermal_data * __devinit thermal_tegra_dt_parse_pdata(
__dev* no longer exists.
> + tdata = devm_kzalloc(&pdev->dev, sizeof(*tdata), GFP_KERNEL);
> + if (!tdata) {
> + dev_err(&pdev->dev, "Can't all
On Sat, Feb 16, 2013 at 10:07:39AM +, Arnd Bergmann wrote:
> On Saturday 16 February 2013, Viresh Kumar wrote:
> > On 15 February 2013 23:51, Arnd Bergmann wrote:
> > > +static bool dw_dma_generic_filter(struct dma_chan *chan, void *param)
> > > {
> >
> > > + dws->cfg_hi = 0xff
On Wed, Feb 13, 2013 at 06:34:32PM +0100, Philipp Zabel wrote:
> Signed-off-by: Philipp Zabel
Just be aware that PXA has a "gpio reset" facility which is used for SoC
reset - see arch/arm/mach-pxa/reset.c
The use of gpio-reset would be ambiguous... or maybe PXA's usage could be
combined somehow
On Sun, Feb 10, 2013 at 02:49:21AM +0100, Javier Martinez Canillas wrote:
> I knew this would be controversial and that's why I didn't mean it to be a
> patch
> but a RFC :)
>
> The problem basically is that you have to associate the platform device with
> its
> corresponding DT device node beca
On Sat, Feb 09, 2013 at 09:35:53PM +0530, Sekhar Nori wrote:
> On 2/1/2013 11:52 PM, Matt Porter wrote:
> > + ret = of_address_to_resource(node, 1, &res);
>
> of_address_to_resource() needs
>
> > + if (IS_ERR_VALUE(ret))
>
> This needs
More importantly, is this the correct way to check fo
On Wed, Feb 06, 2013 at 03:03:16PM -0600, Jon Hunter wrote:
> @@ -673,7 +702,7 @@ static int omap_dma_init(void)
> {
> int rc = platform_driver_register(&omap_dma_driver);
>
> - if (rc == 0) {
> + if ((rc == 0) && (!of_have_populated_dt())) {
Looks good, the worst I can find is th
On Thu, Feb 07, 2013 at 10:15:48PM +0100, Arnd Bergmann wrote:
> On Thursday 07 February 2013 21:19:04 Linus Walleij wrote:
> > On Thu, Feb 7, 2013 at 8:42 PM, Arnd Bergmann wrote:
> > > On Thursday 07 February 2013, Linus Walleij wrote:
> >
> > >> Actually I once read about a feature where the k
On Thu, Feb 07, 2013 at 07:29:17PM +0100, Linus Walleij wrote:
> Actually I once read about a feature where the kernel provides
> a static page full of zeroes or something like this, that would be
> ideal to use in cases like this, then all of this dummy page
> allocation and freeing can be deleted
On Tue, Feb 05, 2013 at 09:41:48PM +0100, Thierry Reding wrote:
> On Wed, Jan 09, 2013 at 09:43:06PM +0100, Thierry Reding wrote:
> > When using deferred driver probing, PCI host controller drivers may
> > actually require this function after the init stage.
> >
> > Signed-off-by: Thierry Reding
On Tue, Feb 05, 2013 at 04:30:45PM +0100, Linus Walleij wrote:
> On Mon, Feb 4, 2013 at 10:54 PM, Cyril Chemparathy wrote:
> > On 02/04/2013 04:11 PM, Linus Walleij wrote:
>
> >> Cyril, just stack up the cookies and take a sweep over them to see
> >> which ones are baked when the NAPI poll comes
On Tue, Feb 05, 2013 at 04:47:05PM +, Mark Brown wrote:
> On Tue, Feb 05, 2013 at 05:21:48PM +0100, Linus Walleij wrote:
>
> > For IRQ mode, use the completion callback to push each cookie
> > to NAPI, and thus let the IRQ drive the traffic.
>
> The whole purpose of NAPI is to avoid taking in
On Mon, Feb 04, 2013 at 04:54:45PM -0500, Cyril Chemparathy wrote:
> You're assuming that cookies complete in order. That is not necessarily
> true.
Under what circumstances is that not true?
___
devicetree-discuss mailing list
devicetree-discuss@list
On Mon, Feb 04, 2013 at 09:47:38PM +, Arnd Bergmann wrote:
> On Monday 04 February 2013, Linus Walleij wrote:
> > So I think the above concerns are moot. The callback we can
> > set on cookies is entirely optional, and it's even implemented by
> > each DMA engine, and some may not even support
On Tue, Feb 05, 2013 at 06:36:34AM +, Vishwanathrao Badarkhe, Manish wrote:
> I made following changes, in order to update "dip->p" pointer with
> correct value:
>
> - if (!dpi->p) {
> + if (IS_ERR_OR_NULL(dpi->p)) {
> dpi->p = devm_pinctrl_get(dev);
> -
On Mon, Feb 04, 2013 at 06:47:12PM +0200, Felipe Balbi wrote:
> Hi,
>
> On Mon, Feb 04, 2013 at 08:36:38PM +0300, Sergei Shtylyov wrote:
> >In my eyes, getting rid of the mess doesn't justify breaking the rules
> > that
> > Russell formulated above.
>
> MUSB is no PCI, there is no single, st
On Mon, Feb 04, 2013 at 05:41:53PM +0200, Felipe Balbi wrote:
> Hi,
>
> On Fri, Feb 01, 2013 at 09:30:03PM +, Russell King - ARM Linux wrote:
> > > > > I guess to make the MUSB side simpler we would need musb-dma-engine
> > > > > glue
> > > &g
On Sat, Feb 02, 2013 at 08:27:42PM +0400, Sergei Shtylyov wrote:
>> There are two people on this thread CC list who were also involved or
>> CC'd on the mails from the thread in 2010... Tony and Felipe.
>> Unfortunately, the person who agreed to do the work is no longer in the
>> land of the livin
On Fri, Feb 01, 2013 at 10:41:08AM -0800, Tony Lindgren wrote:
> * Matt Porter [130201 10:25]:
> > Move mach-davinci/dma.c to common/edma.c so it can be used
> > by OMAP (specifically AM33xx) as well.
>
> I think this should rather go to drivers/dma/?
Yes, it should, but just like OMAP, there's
On Fri, Feb 01, 2013 at 01:59:59PM -0500, Matt Porter wrote:
> On Fri, Feb 01, 2013 at 07:52:46PM +, Sergei Shtylyov wrote:
> > Hello.
> >
> > On 02/01/2013 09:49 PM, Matt Porter wrote:
> >
> > >>> Move mach-davinci/dma.c to common/edma.c so it can be used
> > >>> by OMAP (specifically AM33xx
On Sat, Feb 02, 2013 at 10:18:51AM +, Russell King - ARM Linux wrote:
> On Sat, Feb 02, 2013 at 06:09:24AM +0400, Sergei Shtylyov wrote:
> > Hello.
> >
> > On 02-02-2013 4:44, Russell King - ARM Linux wrote:
> >
> >>>>> On Fri, Feb 01, 20
On Sat, Feb 02, 2013 at 06:09:24AM +0400, Sergei Shtylyov wrote:
> Hello.
>
> On 02-02-2013 4:44, Russell King - ARM Linux wrote:
>
>>>>> On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote:
>>>>>>> good point, do you wanna send some
On Sat, Feb 02, 2013 at 04:07:59AM +0400, Sergei Shtylyov wrote:
> Hello.
>
> On 02-02-2013 1:30, Russell King - ARM Linux wrote:
>
>>> On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote:
>>>>> good point, do you wanna send some patches ?
>
>
On Fri, Feb 01, 2013 at 10:56:00PM +0200, Felipe Balbi wrote:
> hi,
>
> On Fri, Feb 01, 2013 at 11:49:11PM +0300, Sergei Shtylyov wrote:
> > > good point, do you wanna send some patches ?
> >
> >I have already sent them countless times and even stuck CPPI 4.1 support
> > (in
> > arch/arm/com
1 - 100 of 369 matches
Mail list logo
