All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Shawn Guo @ 2011-10-24 14:51 UTC (permalink / raw)
  To: Grant Likely
  Cc: Mark Brown, Rajendra Nayak, patches, tony, devicetree-discuss,
	linux-kernel, linux-omap, lrg, linux-arm-kernel
In-Reply-To: <20111024135950.GV8708@ponder.secretlab.ca>

On Mon, Oct 24, 2011 at 03:59:50PM +0200, Grant Likely wrote:
> On Mon, Oct 24, 2011 at 09:40:26PM +0800, Shawn Guo wrote:
> > On Mon, Oct 24, 2011 at 03:06:37PM +0200, Mark Brown wrote:
> > > On Mon, Oct 24, 2011 at 09:04:31PM +0800, Shawn Guo wrote:
> > > 
> > > > If we can attach the device_node of 'regulators' node to dev->of_node
> > > > when calling regulator_register(regulator_desc, dev, ...) from
> > > > regulator driver, the regulator core will be able to find all nodes under
> > > > 'regulators' using for_each_child_of_node(dev->of_node, child).
> > > 
> > > Please provide concrete examples of the bindings you're talking about,
> > > the really important thing here is how sane the bindings look and I've
> > > really got no idea what any of what you're talking about will look like
> > > or if they make sense.
> > > 
> > The only thing different from what I attached last time is the
> > compatible string added to 'regulators' node.
> > 
> >         ecspi@70010000 { /* ECSPI1 */
> >                 fsl,spi-num-chipselects = <2>;
> >                 cs-gpios = <&gpio3 24 0>, /* GPIO4_24 */
> >                            <&gpio3 25 0>; /* GPIO4_25 */
> >                 status = "okay";
> > 
> >                 pmic: mc13892@0 {
> >                         #address-cells = <1>;
> >                         #size-cells = <0>;
> >                         compatible = "fsl,mc13892";
> >                         spi-max-frequency = <6000000>;
> >                         reg = <0>;
> >                         mc13xxx-irq-gpios = <&gpio0 8 0>; /* GPIO1_8 */
> > 
> >                         regulators {
> >                         	compatible = "fsl,mc13892-regulator";
> > 
> >                                 sw1reg: mc13892_sw1 {
> >                                         regulator-min-uV = <600000>;
> >                                         regulator-max-uV = <1375000>;
> >                                         regulator-change-voltage;
> >                                         regulator-boot-on;
> >                                         regulator-always-on;
> >                                 };
> > 
> >                                 sw2reg: mc13892_sw2 {
> >                                         regulator-min-uV = <900000>;
> >                                         regulator-max-uV = <1850000>;
> >                                         regulator-change-voltage;
> >                                         regulator-boot-on;
> >                                         regulator-always-on;
> >                                 };
> > 
> >                                 ......
> >                         };
> > 
> >                         leds {
> >                                 ......
> >                         };
> > 
> >                         buttons {
> >                                 ......
> >                         };
> >                 };
> > 
> >                 flash: at45db321d@1 {
> >                         ......
> >                 };
> >         };
> > 
> > > > hesitate to hack this into mfd_add_devices(), so I would like to add
> > > > compatible string "fsl,mc13892-regulators" to node 'regulators' and
> > > > find the node using of_find_compatible_node(dev->parent, NULL,
> > > > "fsl,mc13892-regulators").
> > > 
> > > It's not immediately obvious to me that having a binding for the
> > > regulators separately makes sense, it's not a usefully distinct device.
> > > 
> > Fair point.  Actually, I also hate to have the finding of node
> > 'regulators' plugged into regulator driver.  What about following
> > change to address Grant's concern on global device tree search?
> >  
> > diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> > index 8fe132d..29dcf90 100644
> > --- a/drivers/regulator/core.c
> > +++ b/drivers/regulator/core.c
> > @@ -2673,7 +2673,8 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
> >         BLOCKING_INIT_NOTIFIER_HEAD(&rdev->notifier);
> > 
> >         /* find device_node and attach it */
> > -       rdev->dev.of_node = of_find_node_by_name(NULL, regulator_desc->name);
> > +       rdev->dev.of_node = of_find_node_by_name(dev->parent->of_node,
> > +                                                regulator_desc->name);
> 
> of_find_node_by_name() doesn't work that way.  The first argument is a
> starting point, but it doesn't restrict the search to children of a
> node.
> 
> for_each_child_of_node() is what you want to use when iterating over
> the children which unfortunately changes the structure of this
> function.
> 
The dev->parent->of_node is meant to point to node 'pmic: mc13892@0'.
And the intention here is not to iterate over the children, but to
start a search from a reasonable point rather than the top root node.

-- 
Regards,
Shawn


^ permalink raw reply

* Re: [PATCH V2] AT91: dt: at91sam9g45 family and board device tree files
From: Nicolas Ferre @ 2011-10-24 14:42 UTC (permalink / raw)
  To: Grant Likely
  Cc: Rob Herring, devicetree-discuss, Jean-Christophe PLAGNIOL-VILLARD,
	linux-kernel, linux-arm-kernel
In-Reply-To: <20111024143451.GA8708@ponder.secretlab.ca>

On 10/24/2011 04:34 PM, Grant Likely :
> On Tue, Oct 18, 2011 at 12:07:17PM +0200, Nicolas Ferre wrote:
>> On 10/07/2011 02:56 PM, Nicolas Ferre :
>>> On 10/05/2011 03:00 PM, Rob Herring :
>>>> Nicolas,
>>>>
>>>> On 10/03/2011 05:00 AM, Nicolas Ferre wrote:
>>>>> Create a new device tree source file for Atmel at91sam9g45 SoC family.
>>>>> The Evaluation Kit at91sam9m10g45ek includes it.
>>>>> This first basic support will be populated as drivers and boards will be
>>>>> converted to device tree.
>>>>> Contains serial, dma and interrupt controllers.
>>>>>
>>>>> The generic board file still takes advantage of platform data for early serial
>>>>> init. As we need a storage media and the NAND flash driver is not converted to
>>>>> DT yet, we keep old initialization for it.
>>>>>
>>>>> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>>
>> [..]
>>
>>>>> diff --git a/arch/arm/mach-at91/board-dt.c b/arch/arm/mach-at91/board-dt.c
>>>>> new file mode 100644
>>>>> index 0000000..7bcb9a9
>>>>> --- /dev/null
>>>>> +++ b/arch/arm/mach-at91/board-dt.c
>>>>> @@ -0,0 +1,122 @@
>>>>> +/*
>>>>> + *  Setup code for AT91SAM Evaluation Kits with Device Tree support
>>>>> + *
>>>>> + *  Covers: * AT91SAM9G45-EKES  board
>>>>> + *          * AT91SAM9M10-EKES  board
>>>>> + *          * AT91SAM9M10G45-EK board
>>>>> + *
>>>>> + *  Copyright (C) 2011 Atmel,
>>>>> + *                2011 Nicolas Ferre <nicolas.ferre@atmel.com>
>>>>> + *
>>>>> + * Licensed under GPLv2 or later.
>>>>> + */
>>>>> +
>>>>> +#include <linux/types.h>
>>>>> +#include <linux/init.h>
>>>>> +#include <linux/module.h>
>>>>> +#include <linux/irqdomain.h>
>>>>> +#include <linux/of_irq.h>
>>>>> +#include <linux/of_platform.h>
>>>>> +
>>>>> +#include <mach/hardware.h>
>>>>> +#include <mach/board.h>
>>>>> +#include <mach/gpio.h>
>>>>> +#include <mach/system_rev.h>
>>>>> +#include <mach/at91sam9_smc.h>
>>>>> +
>>>>> +#include <asm/setup.h>
>>>>> +#include <asm/irq.h>
>>>>> +#include <asm/mach/arch.h>
>>>>> +#include <asm/mach/map.h>
>>>>> +#include <asm/mach/irq.h>
>>>>> +
>>>>> +#include "sam9_smc.h"
>>>>> +#include "generic.h"
>>
>> As found by Jean-Christophe, it seems that some clock lookup data are missing here. Something like:
>>
>> +/*
>> + * Lookup table for attaching a specific name and platform_data pointer to
>> + * devices as they get created by of_platform_populate(). Ideally this table
>> + * would not exist, but the current clock implementation depends on some devices
>> + * having a specific name.
>> + /
>> +static const struct of_dev_auxdata at91_auxdata_lookup[] __initconst = {
>> + / at91sam9260/ at91sam9g20 /
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffff200, "atmel_usart.0", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffb0000, "atmel_usart.1", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffb4000, "atmel_usart.2", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffb8000, "atmel_usart.3", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffd0000, "atmel_usart.4", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffd4000, "atmel_usart.5", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffd8000, "atmel_usart.6", NULL),
>> + / at91sam9g45*/
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xffffee00, "atmel_usart.0", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff8c000, "atmel_usart.1", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff90000, "atmel_usart.2", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff94000, "atmel_usart.3", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff98000, "atmel_usart.4", NULL),
>> + { /* sentinel */ }
>> +};
>>
>> With a change here:
>>   of_platform_populate(NULL, of_default_bus_match_table, at91_auxdata_lookup, NULL);
>>
>> I know that it is a temporary usage of auxdata. Does it sound the right thing to do for the moment?
> 
> yes.

Grant,

It seems that Rob has had another idea. He advices me (on a Oct. 20th
email) that I should add some clock lookup entries.
That is what I did in a couple of patches that I have just sent some
minutes ago... I tend to like the clock lookup adding more as it prevent
the adding of big amount of code into the board-dt.c file.

What is the preferred option? Are you fine with patches that I have just
sent?

Thanks,

Best regards,
-- 
Nicolas Ferre

^ permalink raw reply

* Re: [xen-unstable bisection] complete test-i386-i386-pair
From: Ian Jackson @ 2011-10-24 14:42 UTC (permalink / raw)
  To: xen-devel@lists.xensource.com, Keir (Xen.org), Stefano Stabellini
In-Reply-To: <E1RIL73-0004qU-9L@woking.xci-test.com>

xen.org writes ("[xen-unstable bisection] complete test-i386-i386-pair"):
> *** Found and reproduced problem changeset ***
> 
>   Bug is in tree:  xen http://xenbits.xen.org/staging/xen-unstable.hg
>   Bug introduced:  1c8789852eaf
>   Bug not present: 8269826353d8
> 
> 
>   changeset:   23990:1c8789852eaf
>   user:        Jan Beulich <jbeulich@suse.com>
>   date:        Fri Oct 21 09:44:47 2011 +0200
>       
>       x86/hpet: allocate CPU masks dynamically
>       
>       Signed-off-by: Jan Beulich <jbeulich@suse.com>
>       Acked-by: Keir Fraser <keir@xen.org>

Looking at the log, it seems that both the source and destination host
for the migration test crashed.

http://www.chiark.greenend.org.uk/~xensrcts/logs/9471/test-i386-i386-pair/info.html

Oct 23 01:36:23.433334 (XEN) ----[ Xen-4.2-unstable  x86_32p  debug=y  Not tainted ]----
Oct 23 01:36:44.057278 (XEN) CPU:    0
Oct 23 01:36:44.057308 (XEN) EIP:    e008:[<ff146151>] __find_first_bit+0x1d/0x3c
Oct 23 01:36:44.069240 (XEN) EFLAGS: 00010246   CONTEXT: hypervisor
Oct 23 01:36:44.069273 (XEN) eax: 00000000   ebx: 00000000   ecx: 00000001   edx: 00000045
Oct 23 01:36:44.077245 (XEN) esi: ff2180e0   edi: 00000000   ebp: ff253e34   esp: ff253e2c
Oct 23 01:36:44.077282 (XEN) cr0: 8005003b   cr4: 000426f0   cr3: 00bdf220   cr2: 00000000
Oct 23 01:36:44.089247 (XEN) ds: e010   es: e010   fs: 00d8   gs: 0000   ss: e010   cs: e008
Oct 23 01:36:44.097240 (XEN) Xen stack trace from esp=ff253e2c:
Oct 23 01:36:44.097271 (XEN)    00000002 ffbe4080 ff253e94 ff17fccc 00000000 00000002 bbcbc1c2 00000045
Oct 23 01:36:44.109238 (XEN)    ff253fb0 ffbe4094 f3520d09 00000045 ff253ebc ff11649d ffbfdddc ff27f180
Oct 23 01:36:44.109278 (XEN)    00000000 00000000 00000000 00000000 00989680 ff27fa80 bbcbc1c2 00000000
Oct 23 01:36:44.117253 (XEN)    ff2180e0 ff290080 ff253eb4 ff17f3e5 ffbe4080 ff14539a ff29d000 ff253f58
Oct 23 01:36:44.129244 (XEN)    00000002 ff253ebc ff253ee4 ff1695e0 ff290080 ff290080 ff253ee4 ff14fff5
Oct 23 01:36:44.129284 (XEN)    ff290080 00000000 00000082 ff253ee4 00000000 ff2180e0 ff253f54 ff154841
Oct 23 01:36:44.137258 (XEN)    00000000 00000000 ff253f60 00000045 00000000 ffbdf000 0000001d ff27f020
Oct 23 01:36:44.149240 (XEN)    ffbdf0c8 ff27f100 f30ab8f7 ff290094 00000000 00000000 00000000 ffbd9a80
Oct 23 01:36:44.157243 (XEN)    ff27f100 ff264200 ffffffff ff253fb0 ff253f7c ff120011 00000000 ff253fb0
Oct 23 01:36:44.157281 (XEN)    0000e010 0000e010 00dac08b ff14cf86 ff253f60 ff253fb0 ff27f100 00000000
Oct 23 01:36:44.169273 (XEN)    ff253fb0 ffffffff ff253f8c ff27f080 00f00000 ff14915d 0000e008 00000246
Oct 23 01:36:44.177260 (XEN)    ff253fac ff14ab2c ff253fb8 ff253fa8 ff120083 deadbeef ff29d000 ffbdf000
Oct 23 01:36:44.177301 (XEN)    ff253e38 deadbeef deadbeef 00000000 00000000 c166d350 c1663f94 00000000
Oct 23 01:36:44.189249 (XEN)    00f90000 c10023a7 00000061 00000246 c1663f84 00000069 0000007b 0000007b
Oct 23 01:36:44.197254 (XEN)    000000d8 00000000 00000000 ff29d000 00000000
Oct 23 01:36:44.197285 (XEN) Xen call trace:
Oct 23 01:36:44.209234 (XEN)    [<ff146151>] __find_first_bit+0x1d/0x3c
Oct 23 01:36:44.209267 (XEN)    [<ff17fccc>] handle_hpet_broadcast+0x87/0x263
Oct 23 01:36:44.217247 (XEN)    [<ff17f3e5>] hpet_legacy_irq_tick+0x37/0x45
Oct 23 01:36:44.217281 (XEN)    [<ff1695e0>] timer_interrupt+0x23/0x194
Oct 23 01:36:44.217314 (XEN)    [<ff154841>] do_IRQ+0x4c8/0x573
Oct 23 01:36:44.229241 (XEN)    [<ff14cf86>] common_interrupt+0x56/0x60
Oct 23 01:36:44.229274 (XEN)    [<ff14915d>] default_idle+0x5f/0x64
Oct 23 01:36:44.237248 (XEN)    [<ff14ab2c>] idle_loop+0x41/0x51
Oct 23 01:36:44.237280 (XEN)    
Oct 23 01:36:44.237302 (XEN) Pagetable walk from 00000000:
Oct 23 01:36:44.237334 (XEN)  L3[0x000] = 0000000123a91001 0001bf95
Oct 23 01:36:44.249238 (XEN)  L2[0x000] = 0000000000000000 ffffffff 
Oct 23 01:36:44.249269 (XEN) 
Oct 23 01:36:44.249290 (XEN) ****************************************
Oct 23 01:36:44.257243 (XEN) Panic on CPU 0:
Oct 23 01:36:44.257269 (XEN) FATAL PAGE FAULT
Oct 23 01:36:44.257294 (XEN) [error_code=0000]
Oct 23 01:36:44.257325 (XEN) Faulting linear address: 00000000
Oct 23 01:36:44.269239 (XEN) ****************************************
Oct 23 01:36:44.269269 (XEN) 
Oct 23 01:36:44.269290 (XEN) Reboot in five seconds...

^ permalink raw reply

* Re: [PATCH V2] AT91: dt: at91sam9g45 family and board device tree files
From: Nicolas Ferre @ 2011-10-24 14:42 UTC (permalink / raw)
  To: Grant Likely
  Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20111024143451.GA8708-e0URQFbLeQY2iJbIjFUEsiwD8/FfD2ys@public.gmane.org>

On 10/24/2011 04:34 PM, Grant Likely :
> On Tue, Oct 18, 2011 at 12:07:17PM +0200, Nicolas Ferre wrote:
>> On 10/07/2011 02:56 PM, Nicolas Ferre :
>>> On 10/05/2011 03:00 PM, Rob Herring :
>>>> Nicolas,
>>>>
>>>> On 10/03/2011 05:00 AM, Nicolas Ferre wrote:
>>>>> Create a new device tree source file for Atmel at91sam9g45 SoC family.
>>>>> The Evaluation Kit at91sam9m10g45ek includes it.
>>>>> This first basic support will be populated as drivers and boards will be
>>>>> converted to device tree.
>>>>> Contains serial, dma and interrupt controllers.
>>>>>
>>>>> The generic board file still takes advantage of platform data for early serial
>>>>> init. As we need a storage media and the NAND flash driver is not converted to
>>>>> DT yet, we keep old initialization for it.
>>>>>
>>>>> Signed-off-by: Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
>>
>> [..]
>>
>>>>> diff --git a/arch/arm/mach-at91/board-dt.c b/arch/arm/mach-at91/board-dt.c
>>>>> new file mode 100644
>>>>> index 0000000..7bcb9a9
>>>>> --- /dev/null
>>>>> +++ b/arch/arm/mach-at91/board-dt.c
>>>>> @@ -0,0 +1,122 @@
>>>>> +/*
>>>>> + *  Setup code for AT91SAM Evaluation Kits with Device Tree support
>>>>> + *
>>>>> + *  Covers: * AT91SAM9G45-EKES  board
>>>>> + *          * AT91SAM9M10-EKES  board
>>>>> + *          * AT91SAM9M10G45-EK board
>>>>> + *
>>>>> + *  Copyright (C) 2011 Atmel,
>>>>> + *                2011 Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
>>>>> + *
>>>>> + * Licensed under GPLv2 or later.
>>>>> + */
>>>>> +
>>>>> +#include <linux/types.h>
>>>>> +#include <linux/init.h>
>>>>> +#include <linux/module.h>
>>>>> +#include <linux/irqdomain.h>
>>>>> +#include <linux/of_irq.h>
>>>>> +#include <linux/of_platform.h>
>>>>> +
>>>>> +#include <mach/hardware.h>
>>>>> +#include <mach/board.h>
>>>>> +#include <mach/gpio.h>
>>>>> +#include <mach/system_rev.h>
>>>>> +#include <mach/at91sam9_smc.h>
>>>>> +
>>>>> +#include <asm/setup.h>
>>>>> +#include <asm/irq.h>
>>>>> +#include <asm/mach/arch.h>
>>>>> +#include <asm/mach/map.h>
>>>>> +#include <asm/mach/irq.h>
>>>>> +
>>>>> +#include "sam9_smc.h"
>>>>> +#include "generic.h"
>>
>> As found by Jean-Christophe, it seems that some clock lookup data are missing here. Something like:
>>
>> +/*
>> + * Lookup table for attaching a specific name and platform_data pointer to
>> + * devices as they get created by of_platform_populate(). Ideally this table
>> + * would not exist, but the current clock implementation depends on some devices
>> + * having a specific name.
>> + /
>> +static const struct of_dev_auxdata at91_auxdata_lookup[] __initconst = {
>> + / at91sam9260/ at91sam9g20 /
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffff200, "atmel_usart.0", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffb0000, "atmel_usart.1", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffb4000, "atmel_usart.2", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffb8000, "atmel_usart.3", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffd0000, "atmel_usart.4", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffd4000, "atmel_usart.5", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffd8000, "atmel_usart.6", NULL),
>> + / at91sam9g45*/
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xffffee00, "atmel_usart.0", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff8c000, "atmel_usart.1", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff90000, "atmel_usart.2", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff94000, "atmel_usart.3", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff98000, "atmel_usart.4", NULL),
>> + { /* sentinel */ }
>> +};
>>
>> With a change here:
>>   of_platform_populate(NULL, of_default_bus_match_table, at91_auxdata_lookup, NULL);
>>
>> I know that it is a temporary usage of auxdata. Does it sound the right thing to do for the moment?
> 
> yes.

Grant,

It seems that Rob has had another idea. He advices me (on a Oct. 20th
email) that I should add some clock lookup entries.
That is what I did in a couple of patches that I have just sent some
minutes ago... I tend to like the clock lookup adding more as it prevent
the adding of big amount of code into the board-dt.c file.

What is the preferred option? Are you fine with patches that I have just
sent?

Thanks,

Best regards,
-- 
Nicolas Ferre

^ permalink raw reply

* [PATCH V2] AT91: dt: at91sam9g45 family and board device tree files
From: Nicolas Ferre @ 2011-10-24 14:42 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20111024143451.GA8708@ponder.secretlab.ca>

On 10/24/2011 04:34 PM, Grant Likely :
> On Tue, Oct 18, 2011 at 12:07:17PM +0200, Nicolas Ferre wrote:
>> On 10/07/2011 02:56 PM, Nicolas Ferre :
>>> On 10/05/2011 03:00 PM, Rob Herring :
>>>> Nicolas,
>>>>
>>>> On 10/03/2011 05:00 AM, Nicolas Ferre wrote:
>>>>> Create a new device tree source file for Atmel at91sam9g45 SoC family.
>>>>> The Evaluation Kit at91sam9m10g45ek includes it.
>>>>> This first basic support will be populated as drivers and boards will be
>>>>> converted to device tree.
>>>>> Contains serial, dma and interrupt controllers.
>>>>>
>>>>> The generic board file still takes advantage of platform data for early serial
>>>>> init. As we need a storage media and the NAND flash driver is not converted to
>>>>> DT yet, we keep old initialization for it.
>>>>>
>>>>> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>>
>> [..]
>>
>>>>> diff --git a/arch/arm/mach-at91/board-dt.c b/arch/arm/mach-at91/board-dt.c
>>>>> new file mode 100644
>>>>> index 0000000..7bcb9a9
>>>>> --- /dev/null
>>>>> +++ b/arch/arm/mach-at91/board-dt.c
>>>>> @@ -0,0 +1,122 @@
>>>>> +/*
>>>>> + *  Setup code for AT91SAM Evaluation Kits with Device Tree support
>>>>> + *
>>>>> + *  Covers: * AT91SAM9G45-EKES  board
>>>>> + *          * AT91SAM9M10-EKES  board
>>>>> + *          * AT91SAM9M10G45-EK board
>>>>> + *
>>>>> + *  Copyright (C) 2011 Atmel,
>>>>> + *                2011 Nicolas Ferre <nicolas.ferre@atmel.com>
>>>>> + *
>>>>> + * Licensed under GPLv2 or later.
>>>>> + */
>>>>> +
>>>>> +#include <linux/types.h>
>>>>> +#include <linux/init.h>
>>>>> +#include <linux/module.h>
>>>>> +#include <linux/irqdomain.h>
>>>>> +#include <linux/of_irq.h>
>>>>> +#include <linux/of_platform.h>
>>>>> +
>>>>> +#include <mach/hardware.h>
>>>>> +#include <mach/board.h>
>>>>> +#include <mach/gpio.h>
>>>>> +#include <mach/system_rev.h>
>>>>> +#include <mach/at91sam9_smc.h>
>>>>> +
>>>>> +#include <asm/setup.h>
>>>>> +#include <asm/irq.h>
>>>>> +#include <asm/mach/arch.h>
>>>>> +#include <asm/mach/map.h>
>>>>> +#include <asm/mach/irq.h>
>>>>> +
>>>>> +#include "sam9_smc.h"
>>>>> +#include "generic.h"
>>
>> As found by Jean-Christophe, it seems that some clock lookup data are missing here. Something like:
>>
>> +/*
>> + * Lookup table for attaching a specific name and platform_data pointer to
>> + * devices as they get created by of_platform_populate(). Ideally this table
>> + * would not exist, but the current clock implementation depends on some devices
>> + * having a specific name.
>> + /
>> +static const struct of_dev_auxdata at91_auxdata_lookup[] __initconst = {
>> + / at91sam9260/ at91sam9g20 /
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffff200, "atmel_usart.0", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffb0000, "atmel_usart.1", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffb4000, "atmel_usart.2", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffb8000, "atmel_usart.3", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffd0000, "atmel_usart.4", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffd4000, "atmel_usart.5", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffd8000, "atmel_usart.6", NULL),
>> + / at91sam9g45*/
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xffffee00, "atmel_usart.0", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff8c000, "atmel_usart.1", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff90000, "atmel_usart.2", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff94000, "atmel_usart.3", NULL),
>> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff98000, "atmel_usart.4", NULL),
>> + { /* sentinel */ }
>> +};
>>
>> With a change here:
>>   of_platform_populate(NULL, of_default_bus_match_table, at91_auxdata_lookup, NULL);
>>
>> I know that it is a temporary usage of auxdata. Does it sound the right thing to do for the moment?
> 
> yes.

Grant,

It seems that Rob has had another idea. He advices me (on a Oct. 20th
email) that I should add some clock lookup entries.
That is what I did in a couple of patches that I have just sent some
minutes ago... I tend to like the clock lookup adding more as it prevent
the adding of big amount of code into the board-dt.c file.

What is the preferred option? Are you fine with patches that I have just
sent?

Thanks,

Best regards,
-- 
Nicolas Ferre

^ permalink raw reply

* Re: fedora 16,64bit,8192drive
From: Larry Finger @ 2011-10-24 14:42 UTC (permalink / raw)
  To: 韩刚; +Cc: wireless
In-Reply-To: <CAC8FjyFZVrZRqyO3eYANH6yaaRgopd==mqHvF6hDiO2ABOA-9Q@mail.gmail.com>

On 10/24/2011 09:33 AM, 韩刚 wrote:
> Dear Larry Finger !
> Thank you for your reply!
> You can sen that,I downloaded the sources ,it's 
> 92ce_se_de_linux_mac80211_0004.0816.2011.tar.gz , extract the tar ,and used the 
> terminal,cd it,made,it error,the information what gave you in the last email.
> which step had error,as you knew that I had installed the 
> kernel,kernel-devel,kernel-headers,and so on.
> How to fix it,from the information which I gave you last mail,it's the format of 
> variable,I tried to fix it,failed.
> So,where are you means the diver or firmware ,or the compat-wireless package?
> I just first use the 64bit's linux,problems are too many to usual to use it!

The driver from the Realtek web site is not different from the one in the
kernel. If you are having problems with it, then you need to document them. In
addition, do not drop any of the Cc's. I only do private debugging when I have a
contract.

Larry



^ permalink raw reply

* Re: [Intel-gfx] [PATCH 1/2] Give up on edid retries when i2c tells us that bus is not there
From: Eugeni Dodonov @ 2011-10-24 14:40 UTC (permalink / raw)
  To: Jean Delvare; +Cc: Michael Buesch, dri-devel
In-Reply-To: <20111020143339.59270702@endymion.delvare>


[-- Attachment #1.1: Type: text/plain, Size: 4071 bytes --]

On Thu, Oct 20, 2011 at 10:33, Jean Delvare <khali@linux-fr.org> wrote:

> Just to clarify: by "connectivity is setup", do you mean code in the
> driver setting the GPIO pin direction etc., or a display being
> connected to the graphics card?
>
> I admit I am a little surprised. I2C buses should have their lines up
> by default, thanks to pull-up resistors, and masters and slaves should
> merely drive the lines low as needed. The absence of slaves should have
> no impact on the line behavior. If the Intel graphics chips (or the
> driver) rely on the display to hold the lines high, I'd say this is a
> seriously broken design.
>
> As a side note, I thought that HDMI had the capability of presence
> detection, so there may be a better way to know if a display is
> connected or not, and this information could used to dynamically
> instantiate and delete the I2C buses? That way we could skip probing
> for EDID when there is no chance of success.
>

Yes, I think so too.

I admit I haven't got to the root of the problem here. My test was really
simple, borrowed from the test_bus() at i2c-algo-bit.c - without HDMI cable
plugged in, I was getting the "SDA stuck high" messages; with the cable
plugged in, I wasn't getting any of those.

But in any case, I haven't investigated it deeper in the hardware direction
after figuring out that drm_get_edid would retry its attempts for retreiving
the edid for 15 times, getting the -ENXIO error for all of them.


> Well, you could always do manual line testing of the I2C bus _before_
> calling drm_do_probe_ddc_edid()? And skip the call if the test fails
> (i.e. the bus isn't ready for use.) As said before, I am willing to
> export bit_test if it helps any. I've attached a patch doing exactly
> this. Let me know if you want me to commit it.
>

Yes, surely, I can do this. I did a similar test in the i915-specific patch,
checking if we can talk to i2c adapter pior to call drm_do_probe_ddc_edid,
but I thought that perhaps it would be easier for all the cards relying on
drm_get_edid to have a faster return path in case of problems.

I am fine with any solution, if this problem is happening to appear on i915
cards only, we could do this in our driver. It is that 15 attempts looks a
bit overkill.


> Your proposed patch is better than I first thought. I had forgotten
> that i2c-algo-bit tries up to 3 times to get a first ack from a slave.
> So if i2c_transfer returns -ENXIO, this means that i2c-algo-bit has
> already attempted 3 times to contact the slave, with no reply, so
> there's probably no point going on. A communication problem with a
> present slave would have returned a different error code.
>
> Without your patch, a missing slave would cause 3 * 5 = 15 retries,
> which is definitely too much.
>
> That being said, even then the whole probe sequence shouldn't exceed
> 10 ms, which I wouldn't expect a user to notice. The user-reported 4
> second delay when running xrandr can't be caused by this. 4 seconds for
> 15 attempts is 250 ms per attempt, this looks like a timeout due to
> non-functional bus, not a nack. Not that 250 ms is 1 jiffy for HZ=250,
> which I guess was what the reporting user was running. So even with
> your patch, there's still 750 ms to wait, I don't think this is
> acceptable. You really have to fix that I2C bus or skip probing it.
>

Yep, true. I've followed the easiest route so far - find out where the
initial problem happens, and attempt at solving it. This change in
drm_get_edid solves the delay at its origin, but we certainly could have
additional delays propagated somewhere else. I couldn't reproduce the
original reporter's huge delay, so I looked at what was within my reach.

In any case - looking at a faster way to leave the drm_do_probe_ddc_edid,
while also allowing a way for having a more detailed probing - would it be
an acceptable solution to add a:

MODULE_PARM(skip_unresponsive_edid, "Ignore outputs which do not provide
edid on first attempt");

and update the patch to use this option?

-- 
Eugeni Dodonov
<http://eugeni.dodonov.net/>

[-- Attachment #1.2: Type: text/html, Size: 4966 bytes --]

[-- Attachment #2: Type: text/plain, Size: 159 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

^ permalink raw reply

* Re: [PATCH v2 3/5] regulator: helper routine to extract regulator_init_data
From: Shawn Guo @ 2011-10-24 14:47 UTC (permalink / raw)
  To: Mark Brown
  Cc: Grant Likely, Rajendra Nayak, patches, tony, devicetree-discuss,
	linux-kernel, linux-omap, lrg, linux-arm-kernel
In-Reply-To: <20111024134930.GD26033@opensource.wolfsonmicro.com>

On Mon, Oct 24, 2011 at 03:49:30PM +0200, Mark Brown wrote:
> On Mon, Oct 24, 2011 at 09:40:26PM +0800, Shawn Guo wrote:
> 
> > +++ b/drivers/regulator/core.c
> > @@ -2673,7 +2673,8 @@ struct regulator_dev *regulator_register(struct regulator_desc *regulator_desc,
> >         BLOCKING_INIT_NOTIFIER_HEAD(&rdev->notifier);
> > 
> >         /* find device_node and attach it */
> > -       rdev->dev.of_node = of_find_node_by_name(NULL, regulator_desc->name);
> > +       rdev->dev.of_node = of_find_node_by_name(dev->parent->of_node,
> > +                                                regulator_desc->name);
> > 
> 
> Is that going to do the right thing if you've got a MFD which does
> register each regulator as a separate device?

Based on my understanding, 1:1 is just a special case of N:1.  I
failed to see any problem having it work with registering each
regulator as a separate device.

> Might be best to just
> search within dev and get drivers to pass the "real" device in when
> registering the regulator rather than the virtual device.
> 
It should also work, but it will also change the API slightly for
non-dt users.  I'm not sure it's something we want.

-- 
Regards,
Shawn


^ permalink raw reply

* Re: [RFC][PATCH] KVM: Introduce direct MSI message injection for in-kernel irqchips
From: Michael S. Tsirkin @ 2011-10-24 14:40 UTC (permalink / raw)
  To: Jan Kiszka; +Cc: Avi Kivity, Marcelo Tosatti, kvm
In-Reply-To: <4EA56B99.2030201@siemens.com>

On Mon, Oct 24, 2011 at 03:43:53PM +0200, Jan Kiszka wrote:
> On 2011-10-24 15:11, Jan Kiszka wrote:
> > On 2011-10-24 14:43, Michael S. Tsirkin wrote:
> >> On Mon, Oct 24, 2011 at 02:06:08PM +0200, Jan Kiszka wrote:
> >>> On 2011-10-24 13:09, Avi Kivity wrote:
> >>>> On 10/24/2011 12:19 PM, Jan Kiszka wrote:
> >>>>>>
> >>>>>> With the new feature it may be worthwhile, but I'd like to see the whole
> >>>>>> thing, with numbers attached.
> >>>>>
> >>>>> It's not a performance issue, it's a resource limitation issue: With the
> >>>>> new API we can stop worrying about user space device models consuming
> >>>>> limited IRQ routes of the KVM subsystem.
> >>>>>
> >>>>
> >>>> Only if those devices are in the same process (or have access to the
> >>>> vmfd).  Interrupt routing together with irqfd allows you to disaggregate
> >>>> the device model.  Instead of providing a competing implementation with
> >>>> new limitations, we need to remove the limitations of the old
> >>>> implementation.
> >>>
> >>> That depends on where we do the cut. Currently we let the IRQ source
> >>> signal an abstract edge on a pre-allocated pseudo IRQ line. But we
> >>> cannot build correct MSI-X on top of the current irqfd model as we lack
> >>> the level information (for PBA emulation). *)
> >>
> >>
> >> I don't agree here. IMO PBA emulation would need to
> >> clear pending bits on interrupt status register read.
> >> So clearing pending bits could be done by ioctl from qemu
> >> while setting them would be done from irqfd.
> > 
> > How should QEMU know if the reason for "pending" has been cleared at
> > device level if the device is outside the scope of QEMU? This model only
> > works for PV devices when you agree that spurious IRQs are OK.
> > 
> >>
> >>> So we either need to
> >>> extend the existing model anyway -- or push per-vector masking back to
> >>> the IRQ source. In the latter case, it would be a very good chance to
> >>> give up on limited pseudo GSIs with static routes and do MSI messaging
> >>> from external IRQ sources to KVM directly.
> >>> But all those considerations affect different APIs than what I'm
> >>> proposing here. We will always need a way to inject MSIs in the context
> >>> of the VM as there will always be scenarios where devices are better run
> >>> in that very same context, for performance or simplicity or whatever
> >>> reasons. E.g., I could imagine that one would like to execute an
> >>> emulated IRQ remapper rather in the hypervisor context than
> >>> "over-microkernelized" in a separate process.
> >>>
> >>> Jan
> >>>
> >>> *) Realized this while trying to generalize the proposed MSI-X MMIO
> >>> acceleration for assigned devices to arbitrary device models, vhost-net,
> >>
> >> I'm actually working on a qemu patch to get pba emulation working correctly.
> >> I think it's doable with existing irqfd.
> > 
> > irqfd has no notion of level. You can only communicate a rising edge and
> > then need a side channel for the state of the edge reason.
> > 
> >>
> >>> and specifically vfio.
> >>
> >> Interesting. How would you clear the pseudo interrupt level?
> > 
> > Ideally: not at all (for MSI). If we manage the mask at device level, we
> > only need to send the message if there is actually something to deliver
> > to the interrupt controller and masked input events would be lost on
> > real HW as well.
> 
> This wouldn't work out nicely as well. We rather need a combined model:
> 
> Devices need to maintain the PBA actively, i.e. set & clear them
> themselves and do not rely on the core here (with the core being either
> QEMU user space or an in-kernel MSI-X MMIO accelerator). The core only
> checks the PBA if it is about to deliver some message and refrains from
> doing so if the bit became 0 in the meantime (specifically during the
> masked period).
>
> For QEMU device models, that means no additional IOCTLs,
> just memory sharing of the PBA which is required anyway.

Sorry, I don't understand the above two paragraphs. Maybe I am
confused by terminology here. We really only need to check PBA when it's
read.  Whether the message is delivered only depends on the mask bit.


> 
> But that means QEMU-external device models need to gain at least basic
> MSI-X knowledge. And if they gain this awareness, they could also use it
> to send full-blown messages directly (e.g. device-id/vector tuples)
> instead of encoding them into finite GSI numbers. But that's an add-on
> topic.
> 
> Moreover, we still need a corresponding side channel for line-base
> interrupts.
> 
> Jan

Agree on all points with the above.

> -- 
> Siemens AG, Corporate Technology, CT T DE IT 1
> Corporate Competence Center Embedded Linux

^ permalink raw reply

* cpufreq for at91? device tree files
From: Robert Schwebel @ 2011-10-24 14:38 UTC (permalink / raw)
  To: linux-arm-kernel

Hi Albin,

I've seen here [1] that you have worked on cpufreq for AT91 back in
2009, but until now it doesn't seem to have hit mainline. Did you
experience problems with the cpufreq code at that time, or didn't you
simplay have the time to continue?

We may have an opportunity to help soon, but I'd like to make sure that
you didn't experience fundamental issues yet :)

rsc

[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2009-August/000145.html
-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

^ permalink raw reply

* Re: problem with intel 5300
From: Guy, Wey-Yi @ 2011-10-24 13:45 UTC (permalink / raw)
  To: Mikael Abrahamsson; +Cc: linux-wireless@vger.kernel.org
In-Reply-To: <alpine.DEB.2.00.1110240746530.11931@uplift.swm.pp.se>

On Sun, 2011-10-23 at 22:48 -0700, Mikael Abrahamsson wrote:
> On Tue, 20 Sep 2011, Mikael Abrahamsson wrote:
> 
> Hi,
> 
> just wanted to say that I have now upgraded to ubuntu 11.10 with its 3.0.x 
> kernel, and I'm now running it with .11n enabled and it's been ok for 20 
> hours. So whatever problem there was in 2.6.38, it seems to have been 
> fixed in 3.0.x, or at least it's working much better.
> 
very happy to hear that, thank you very much for reporting

Wey


^ permalink raw reply

* [PATCH v2] ARM: gic: fix irq_alloc_descs handling for sparse irq
From: Rob Herring @ 2011-10-24 14:36 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1319314808-27007-1-git-send-email-robherring2@gmail.com>

From: Rob Herring <rob.herring@calxeda.com>

Commit "ARM: gic: add irq_domain support" (2071a2a4b8ed5292) broke SPARSE_IRQ
on platforms with GIC. When SPARSE_IRQ is enabled, all NR_IRQS or
mach_desc->nr_irqs will be allocated by arch_probe_nr_irqs(). This caused
irq_alloc_descs to allocate irq_descs after the pre-allocated space.

Make irq_alloc_descs search for an exact irq range and assume it has
been pre-allocated on failure. For DT probing dynamic allocation is used.
DT enabled platforms should set their nr_irqs to NR_IRQ_LEGACY and have all
irq_chips allocate their irq_descs with irq_alloc_descs if SPARSE_IRQ is
enabled.

gic_init irq_start param is changed to be signed with negative meaning do
dynamic Linux irq assigment.

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
---
v2:
 - make irq_start signed

 arch/arm/common/gic.c               |   15 +++++++++++----
 arch/arm/include/asm/hardware/gic.h |    2 +-
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
index 65cf39d..e9debd4 100644
--- a/arch/arm/common/gic.c
+++ b/arch/arm/common/gic.c
@@ -24,6 +24,7 @@
  */
 #include <linux/init.h>
 #include <linux/kernel.h>
+#include <linux/err.h>
 #include <linux/list.h>
 #include <linux/smp.h>
 #include <linux/cpu_pm.h>
@@ -550,7 +551,7 @@ const struct irq_domain_ops gic_irq_domain_ops = {
 #endif
 };
 
-void __init gic_init(unsigned int gic_nr, unsigned int irq_start,
+void __init gic_init(unsigned int gic_nr, int irq_start,
 	void __iomem *dist_base, void __iomem *cpu_base)
 {
 	struct gic_chip_data *gic;
@@ -571,7 +572,8 @@ void __init gic_init(unsigned int gic_nr, unsigned int irq_start,
 	if (gic_nr == 0) {
 		gic_cpu_base_addr = cpu_base;
 		domain->hwirq_base = 16;
-		irq_start = (irq_start & ~31) + 16;
+		if (irq_start > 0)
+			irq_start = (irq_start & ~31) + 16;
 	} else
 		domain->hwirq_base = 32;
 
@@ -586,8 +588,13 @@ void __init gic_init(unsigned int gic_nr, unsigned int irq_start,
 	gic->gic_irqs = gic_irqs;
 
 	domain->nr_irq = gic_irqs - domain->hwirq_base;
-	domain->irq_base = irq_alloc_descs(-1, irq_start, domain->nr_irq,
+	domain->irq_base = irq_alloc_descs(irq_start, 16, domain->nr_irq,
 					   numa_node_id());
+	if (IS_ERR_VALUE(domain->irq_base)) {
+		WARN(1, "Cannot allocate irq_descs @ IRQ%d, assuming pre-allocated\n",
+		     irq_start);
+		domain->irq_base = irq_start;
+	}
 	domain->priv = gic;
 	domain->ops = &gic_irq_domain_ops;
 	irq_domain_add(domain);
@@ -657,7 +664,7 @@ int __init gic_of_init(struct device_node *node, struct device_node *parent)
 
 	domain->of_node = of_node_get(node);
 
-	gic_init(gic_cnt, 16, dist_base, cpu_base);
+	gic_init(gic_cnt, -1, dist_base, cpu_base);
 
 	if (parent) {
 		irq = irq_of_parse_and_map(node, 0);
diff --git a/arch/arm/include/asm/hardware/gic.h b/arch/arm/include/asm/hardware/gic.h
index 1a776a1..0ea4122 100644
--- a/arch/arm/include/asm/hardware/gic.h
+++ b/arch/arm/include/asm/hardware/gic.h
@@ -38,7 +38,7 @@
 extern void __iomem *gic_cpu_base_addr;
 extern struct irq_chip gic_arch_extn;
 
-void gic_init(unsigned int, unsigned int, void __iomem *, void __iomem *);
+void gic_init(unsigned int, int, void __iomem *, void __iomem *);
 int gic_of_init(struct device_node *node, struct device_node *parent);
 void gic_secondary_init(unsigned int);
 void gic_cascade_irq(unsigned int gic_nr, unsigned int irq);
-- 
1.7.5.4

^ permalink raw reply related

* Re: [PATCH V2] AT91: dt: at91sam9g45 family and board device tree files
From: Grant Likely @ 2011-10-24 14:34 UTC (permalink / raw)
  To: Nicolas Ferre
  Cc: Rob Herring, devicetree-discuss, Jean-Christophe PLAGNIOL-VILLARD,
	linux-kernel, linux-arm-kernel
In-Reply-To: <4E9D4FD5.8080802@atmel.com>

On Tue, Oct 18, 2011 at 12:07:17PM +0200, Nicolas Ferre wrote:
> On 10/07/2011 02:56 PM, Nicolas Ferre :
> > On 10/05/2011 03:00 PM, Rob Herring :
> >> Nicolas,
> >>
> >> On 10/03/2011 05:00 AM, Nicolas Ferre wrote:
> >>> Create a new device tree source file for Atmel at91sam9g45 SoC family.
> >>> The Evaluation Kit at91sam9m10g45ek includes it.
> >>> This first basic support will be populated as drivers and boards will be
> >>> converted to device tree.
> >>> Contains serial, dma and interrupt controllers.
> >>>
> >>> The generic board file still takes advantage of platform data for early serial
> >>> init. As we need a storage media and the NAND flash driver is not converted to
> >>> DT yet, we keep old initialization for it.
> >>>
> >>> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> 
> [..]
> 
> >>> diff --git a/arch/arm/mach-at91/board-dt.c b/arch/arm/mach-at91/board-dt.c
> >>> new file mode 100644
> >>> index 0000000..7bcb9a9
> >>> --- /dev/null
> >>> +++ b/arch/arm/mach-at91/board-dt.c
> >>> @@ -0,0 +1,122 @@
> >>> +/*
> >>> + *  Setup code for AT91SAM Evaluation Kits with Device Tree support
> >>> + *
> >>> + *  Covers: * AT91SAM9G45-EKES  board
> >>> + *          * AT91SAM9M10-EKES  board
> >>> + *          * AT91SAM9M10G45-EK board
> >>> + *
> >>> + *  Copyright (C) 2011 Atmel,
> >>> + *                2011 Nicolas Ferre <nicolas.ferre@atmel.com>
> >>> + *
> >>> + * Licensed under GPLv2 or later.
> >>> + */
> >>> +
> >>> +#include <linux/types.h>
> >>> +#include <linux/init.h>
> >>> +#include <linux/module.h>
> >>> +#include <linux/irqdomain.h>
> >>> +#include <linux/of_irq.h>
> >>> +#include <linux/of_platform.h>
> >>> +
> >>> +#include <mach/hardware.h>
> >>> +#include <mach/board.h>
> >>> +#include <mach/gpio.h>
> >>> +#include <mach/system_rev.h>
> >>> +#include <mach/at91sam9_smc.h>
> >>> +
> >>> +#include <asm/setup.h>
> >>> +#include <asm/irq.h>
> >>> +#include <asm/mach/arch.h>
> >>> +#include <asm/mach/map.h>
> >>> +#include <asm/mach/irq.h>
> >>> +
> >>> +#include "sam9_smc.h"
> >>> +#include "generic.h"
> 
> As found by Jean-Christophe, it seems that some clock lookup data are missing here. Something like:
> 
> +/*
> + * Lookup table for attaching a specific name and platform_data pointer to
> + * devices as they get created by of_platform_populate(). Ideally this table
> + * would not exist, but the current clock implementation depends on some devices
> + * having a specific name.
> + /
> +static const struct of_dev_auxdata at91_auxdata_lookup[] __initconst = {
> + / at91sam9260/ at91sam9g20 /
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffff200, "atmel_usart.0", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffb0000, "atmel_usart.1", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffb4000, "atmel_usart.2", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffb8000, "atmel_usart.3", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffd0000, "atmel_usart.4", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffd4000, "atmel_usart.5", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffd8000, "atmel_usart.6", NULL),
> + / at91sam9g45*/
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xffffee00, "atmel_usart.0", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff8c000, "atmel_usart.1", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff90000, "atmel_usart.2", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff94000, "atmel_usart.3", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff98000, "atmel_usart.4", NULL),
> + { /* sentinel */ }
> +};
> 
> With a change here:
>   of_platform_populate(NULL, of_default_bus_match_table, at91_auxdata_lookup, NULL);
> 
> I know that it is a temporary usage of auxdata. Does it sound the right thing to do for the moment?

yes.

g.


^ permalink raw reply

* [PATCH V2] AT91: dt: at91sam9g45 family and board device tree files
From: Grant Likely @ 2011-10-24 14:34 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <4E9D4FD5.8080802@atmel.com>

On Tue, Oct 18, 2011 at 12:07:17PM +0200, Nicolas Ferre wrote:
> On 10/07/2011 02:56 PM, Nicolas Ferre :
> > On 10/05/2011 03:00 PM, Rob Herring :
> >> Nicolas,
> >>
> >> On 10/03/2011 05:00 AM, Nicolas Ferre wrote:
> >>> Create a new device tree source file for Atmel at91sam9g45 SoC family.
> >>> The Evaluation Kit at91sam9m10g45ek includes it.
> >>> This first basic support will be populated as drivers and boards will be
> >>> converted to device tree.
> >>> Contains serial, dma and interrupt controllers.
> >>>
> >>> The generic board file still takes advantage of platform data for early serial
> >>> init. As we need a storage media and the NAND flash driver is not converted to
> >>> DT yet, we keep old initialization for it.
> >>>
> >>> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> 
> [..]
> 
> >>> diff --git a/arch/arm/mach-at91/board-dt.c b/arch/arm/mach-at91/board-dt.c
> >>> new file mode 100644
> >>> index 0000000..7bcb9a9
> >>> --- /dev/null
> >>> +++ b/arch/arm/mach-at91/board-dt.c
> >>> @@ -0,0 +1,122 @@
> >>> +/*
> >>> + *  Setup code for AT91SAM Evaluation Kits with Device Tree support
> >>> + *
> >>> + *  Covers: * AT91SAM9G45-EKES  board
> >>> + *          * AT91SAM9M10-EKES  board
> >>> + *          * AT91SAM9M10G45-EK board
> >>> + *
> >>> + *  Copyright (C) 2011 Atmel,
> >>> + *                2011 Nicolas Ferre <nicolas.ferre@atmel.com>
> >>> + *
> >>> + * Licensed under GPLv2 or later.
> >>> + */
> >>> +
> >>> +#include <linux/types.h>
> >>> +#include <linux/init.h>
> >>> +#include <linux/module.h>
> >>> +#include <linux/irqdomain.h>
> >>> +#include <linux/of_irq.h>
> >>> +#include <linux/of_platform.h>
> >>> +
> >>> +#include <mach/hardware.h>
> >>> +#include <mach/board.h>
> >>> +#include <mach/gpio.h>
> >>> +#include <mach/system_rev.h>
> >>> +#include <mach/at91sam9_smc.h>
> >>> +
> >>> +#include <asm/setup.h>
> >>> +#include <asm/irq.h>
> >>> +#include <asm/mach/arch.h>
> >>> +#include <asm/mach/map.h>
> >>> +#include <asm/mach/irq.h>
> >>> +
> >>> +#include "sam9_smc.h"
> >>> +#include "generic.h"
> 
> As found by Jean-Christophe, it seems that some clock lookup data are missing here. Something like:
> 
> +/*
> + * Lookup table for attaching a specific name and platform_data pointer to
> + * devices as they get created by of_platform_populate(). Ideally this table
> + * would not exist, but the current clock implementation depends on some devices
> + * having a specific name.
> + /
> +static const struct of_dev_auxdata at91_auxdata_lookup[] __initconst = {
> + / at91sam9260/ at91sam9g20 /
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffff200, "atmel_usart.0", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffb0000, "atmel_usart.1", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffb4000, "atmel_usart.2", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffb8000, "atmel_usart.3", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffd0000, "atmel_usart.4", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffd4000, "atmel_usart.5", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfffd8000, "atmel_usart.6", NULL),
> + / at91sam9g45*/
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xffffee00, "atmel_usart.0", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff8c000, "atmel_usart.1", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff90000, "atmel_usart.2", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff94000, "atmel_usart.3", NULL),
> + OF_DEV_AUXDATA("atmel,at91sam9260-usart", 0xfff98000, "atmel_usart.4", NULL),
> + { /* sentinel */ }
> +};
> 
> With a change here:
>   of_platform_populate(NULL, of_default_bus_match_table, at91_auxdata_lookup, NULL);
> 
> I know that it is a temporary usage of auxdata. Does it sound the right thing to do for the moment?

yes.

g.

^ permalink raw reply

* Re: [Qemu-devel] [PATCH V2 09/10] Introduce Xen PCI Passthrough, PCI config space helpers (2/3)
From: Anthony PERARD @ 2011-10-24 14:33 UTC (permalink / raw)
  To: Stefano Stabellini; +Cc: Xen Devel, QEMU-devel
In-Reply-To: <alpine.DEB.2.00.1110201146210.3519@kaball-desktop>

On Thu, Oct 20, 2011 at 12:01, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
>> +    /* disable MSI/MSI-X and MSI-INTx translation */
>> +    if (s->msi) {
>> +        pt_msi_disable(s);
>> +    }
>> +    if (s->msix) {
>> +        pt_msix_disable(s);
>> +    }
>
> these msi functions are not implemented yet

Ok, I will remove all msi related call and define, and move them to
the next patch.

-- 
Anthony PERARD

^ permalink raw reply

* Re: [PATCH V2 09/10] Introduce Xen PCI Passthrough, PCI config space helpers (2/3)
From: Anthony PERARD @ 2011-10-24 14:33 UTC (permalink / raw)
  To: Stefano Stabellini; +Cc: Xen Devel, QEMU-devel
In-Reply-To: <alpine.DEB.2.00.1110201146210.3519@kaball-desktop>

On Thu, Oct 20, 2011 at 12:01, Stefano Stabellini
<stefano.stabellini@eu.citrix.com> wrote:
>> +    /* disable MSI/MSI-X and MSI-INTx translation */
>> +    if (s->msi) {
>> +        pt_msi_disable(s);
>> +    }
>> +    if (s->msix) {
>> +        pt_msix_disable(s);
>> +    }
>
> these msi functions are not implemented yet

Ok, I will remove all msi related call and define, and move them to
the next patch.

-- 
Anthony PERARD

^ permalink raw reply

* Re: [PATCH] TTY: pty, fix pty counting
From: Ilya Zykov @ 2011-10-24 14:33 UTC (permalink / raw)
  To: Jiri Slaby; +Cc: Greg Kroah-Hartman, Alan Cox, linux-kernel, ilya
In-Reply-To: <4EA563E6.3040205@suse.cz>

Jiri Slaby wrote:
> On 10/23/2011 11:01 PM, Ilya Zykov wrote:
>> New version for commit: 24d406a6bf736f7aebdc8fa0f0ec86e0890c6d24
> 
> Although it will work, as ptms are not allowed to be reopen, it doesn't
> look correct. We should decrement the count in ->remove, because we are
> incrementing in install.
> 
> Now, when I understand ptm+devpts layer a bit more, instead of the
> current hackish approach introduced by 24d406a6b (TTY: pty, fix pty
> counting), I think we may introduce a ->remove hook specific to ptms. In
> that one we could decrement the count and don't bother with the
> pty_count macros anymore. Right?
> 
> BTW you cannot remove ->remove hook of pty layer. It would cause an OOPS
> because driver->ttys is not allocated for ptys.
> 
>> diff -uprN a/drivers/tty/pty.c b/drivers/tty/pty.c
>> --- a/drivers/tty/pty.c	2011-05-19 08:06:34.000000000 +0400
>> +++ b/drivers/tty/pty.c	2011-10-23 18:01:20.000000000 +0400
>> @@ -36,13 +36,15 @@
>>  static struct tty_driver *ptm_driver;
>>  static struct tty_driver *pts_driver;
>>  #endif
>> +static int pty_count;
>>  
>>  static void pty_close(struct tty_struct *tty, struct file *filp)
>>  {
>>  	BUG_ON(!tty);
>> -	if (tty->driver->subtype == PTY_TYPE_MASTER)
>> +	if (tty->driver->subtype == PTY_TYPE_MASTER) {
>>  		WARN_ON(tty->count > 1);
>> -	else {
>> +		pty_count--;
>> +	} else {
>>  		if (tty->count > 2)
>>  			return;
>>  	}
>> @@ -446,7 +448,6 @@ static inline void legacy_pty_init(void)
>>  int pty_limit = NR_UNIX98_PTY_DEFAULT;
>>  static int pty_limit_min;
>>  static int pty_limit_max = NR_UNIX98_PTY_MAX;
>> -static int pty_count;
>>  
>>  static struct cdev ptmx_cdev;
>>  
>> @@ -599,15 +600,9 @@ free_mem_out:
>>  	return -ENOMEM;
>>  }
>>  
>> -static void pty_unix98_remove(struct tty_driver *driver, struct tty_struct *tty)
>> -{
>> -	pty_count--;
>> -}
>> -
>>  static const struct tty_operations ptm_unix98_ops = {
>>  	.lookup = ptm_unix98_lookup,
>>  	.install = pty_unix98_install,
>> -	.remove = pty_unix98_remove,
>>  	.open = pty_open,
>>  	.close = pty_close,
>>  	.write = pty_write,
>> @@ -624,7 +619,6 @@ static const struct tty_operations ptm_u
>>  static const struct tty_operations pty_unix98_ops = {
>>  	.lookup = pts_unix98_lookup,
>>  	.install = pty_unix98_install,
>> -	.remove = pty_unix98_remove,
>>  	.open = pty_open,
>>  	.close = pty_close,
>>  	.write = pty_write,
> 
> thanks,

We can increment pty_count in open()
About BTW(->remove) You say in 24d406a6b:
However tty_shutdown() is called from queue_release_one_tty() only if
tty_operations->shutdown is NULL. But for pty, it is not.
pty_unix98_shutdown() is used there as ->shutdown.

So tty_operations->remove of pty (i.e. pty_unix98_remove()) is never
called. This results in invalid pty_count. I.e. what can be seen in
/proc/sys/kernel/pty/nr.

^ permalink raw reply

* [PATCH 2/2] mmc: mmci: add constraints on alignment for SDIO
From: Ulf Hansson @ 2011-10-24 14:33 UTC (permalink / raw)
  To: linux-mmc, linux-arm-kernel
  Cc: Russell King, Ulf Hansson, Lee Jones, Per Forlin,
	Stefan Nilsson XK
In-Reply-To: <1319466800-19884-1-git-send-email-ulf.hansson@stericsson.com>

From: Per Forlin <per.forlin@stericsson.com>

Buffers must be 4 bytes aligned due to restrictions that
the PL18x FIFO accesses must be done in a 4-byte aligned manner.
Enable DMA_REQCTL for SDIO to support write of not 32 bytes aligned
sg element lengths. In PIO mode any buffer length can be handled
as long as the buffer address is 4 byte aligned.

Signed-off-by: Ulf Hansson <ulf.hansson@stericsson.com>
Signed-off-by: Per Forlin <per.forlin@stericsson.com>
Signed-off-by: Stefan Nilsson XK <stefan.xk.nilsson@stericsson.com>
---
 drivers/mmc/host/mmci.c |   55 +++++++++++++++++++++++++++++++++++++++-------
 drivers/mmc/host/mmci.h |    7 ++++++
 2 files changed, 53 insertions(+), 9 deletions(-)

diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index a6387b5..1a46084 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -45,6 +45,7 @@ static unsigned int fmax = 515633;
  * struct variant_data - MMCI variant-specific quirks
  * @clkreg: default value for MCICLOCK register
  * @clkreg_enable: enable value for MMCICLOCK register
+ * @dma_sdio_req_ctrl: enable value for DMAREQCTL register for SDIO write
  * @datalength_bits: number of bits in the MMCIDATALENGTH register
  * @fifosize: number of bytes that can be written when MMCI_TXFIFOEMPTY
  *	      is asserted (likewise for RX)
@@ -58,6 +59,7 @@ static unsigned int fmax = 515633;
 struct variant_data {
 	unsigned int		clkreg;
 	unsigned int		clkreg_enable;
+	unsigned int		dma_sdio_req_ctrl;
 	unsigned int		datalength_bits;
 	unsigned int		fifosize;
 	unsigned int		fifohalfsize;
@@ -92,6 +94,7 @@ static struct variant_data variant_ux500 = {
 	.fifohalfsize		= 8 * 4,
 	.clkreg			= MCI_CLK_ENABLE,
 	.clkreg_enable		= MCI_ST_UX500_HWFCEN,
+	.dma_sdio_req_ctrl	= MCI_ST_DPSM_DMAREQCTL,
 	.datalength_bits	= 24,
 	.sdio			= true,
 	.st_clkdiv		= true,
@@ -102,6 +105,7 @@ static struct variant_data variant_ux500v2 = {
 	.fifohalfsize		= 8 * 4,
 	.clkreg			= MCI_CLK_ENABLE,
 	.clkreg_enable		= MCI_ST_UX500_HWFCEN,
+	.dma_sdio_req_ctrl	= MCI_ST_DPSM_DMAREQCTL,
 	.datalength_bits	= 24,
 	.sdio			= true,
 	.st_clkdiv		= true,
@@ -110,6 +114,31 @@ static struct variant_data variant_ux500v2 = {
 };
 
 /*
+ * Validate mmc prerequisites
+ */
+static int mmci_validate_data(struct mmci_host *host,
+			      struct mmc_data *data)
+{
+	if (!data)
+		return 0;
+
+	if (!host->variant->non_power_of_2_blksize &&
+	    !is_power_of_2(data->blksz)) {
+		dev_err(mmc_dev(host->mmc),
+			"unsupported block size (%d bytes)\n", data->blksz);
+		return -EINVAL;
+	}
+
+	if (data->sg->offset & 3) {
+		dev_err(mmc_dev(host->mmc),
+			"unsupported alginment (0x%x)\n", data->sg->offset);
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+/*
  * This must be called with host->lock held
  */
 static void mmci_set_clkreg(struct mmci_host *host, unsigned int desired)
@@ -401,8 +430,12 @@ static int mmci_dma_prep_data(struct mmci_host *host, struct mmc_data *data,
 	if (!chan)
 		return -EINVAL;
 
-	/* If less than or equal to the fifo size, don't bother with DMA */
-	if (data->blksz * data->blocks <= variant->fifosize)
+	/*
+	 * If less than or equal to the fifo size, don't bother with DMA
+	 * SDIO transfers may not be 4 bytes aligned, fall back to PIO
+	 */
+	if (data->blksz * data->blocks <= variant->fifosize ||
+	    (data->blksz * data->blocks) & 3)
 		return -EINVAL;
 
 	device = chan->device;
@@ -437,6 +470,7 @@ static int mmci_dma_start_data(struct mmci_host *host, unsigned int datactrl)
 {
 	int ret;
 	struct mmc_data *data = host->data;
+	struct variant_data *variant = host->variant;
 
 	ret = mmci_dma_prep_data(host, host->data, NULL);
 	if (ret)
@@ -451,6 +485,11 @@ static int mmci_dma_start_data(struct mmci_host *host, unsigned int datactrl)
 
 	datactrl |= MCI_DPSM_DMAENABLE;
 
+	/* Some hardware versions need special flags for SDIO DMA write */
+	if (variant->sdio && host->mmc->card && mmc_card_sdio(host->mmc->card)
+	    && (data->flags & MMC_DATA_WRITE))
+		datactrl |= variant->dma_sdio_req_ctrl;
+
 	/* Trigger the DMA transfer */
 	writel(datactrl, host->base + MMCIDATACTRL);
 
@@ -495,6 +534,9 @@ static void mmci_pre_request(struct mmc_host *mmc, struct mmc_request *mrq,
 	if (!data)
 		return;
 
+	if (mmci_validate_data(host, mrq->data))
+		return;
+
 	if (data->host_cookie) {
 		data->host_cookie = 0;
 		return;
@@ -976,17 +1018,12 @@ static irqreturn_t mmci_irq(int irq, void *dev_id)
 static void mmci_request(struct mmc_host *mmc, struct mmc_request *mrq)
 {
 	struct mmci_host *host = mmc_priv(mmc);
-	struct variant_data *variant = host->variant;
 	unsigned long flags;
 
 	WARN_ON(host->mrq != NULL);
 
-	if (mrq->data &&
-	    !variant->non_power_of_2_blksize &&
-	    !is_power_of_2(mrq->data->blksz)) {
-		dev_err(mmc_dev(mmc), "unsupported block size (%d bytes)\n",
-			mrq->data->blksz);
-		mrq->cmd->error = -EINVAL;
+	mrq->cmd->error = mmci_validate_data(host, mrq->data);
+	if (mrq->cmd->error) {
 		mmc_request_done(mmc, mrq);
 		return;
 	}
diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
index 79e4143..d2737f0 100644
--- a/drivers/mmc/host/mmci.h
+++ b/drivers/mmc/host/mmci.h
@@ -70,6 +70,13 @@
 #define MCI_ST_DPSM_RWMOD	(1 << 10)
 #define MCI_ST_DPSM_SDIOEN	(1 << 11)
 /* Control register extensions in the ST Micro Ux500 versions */
+/*
+ * DMA request control is required for write
+ * if transfer size is not 32 byte aligned.
+ * DMA request control is also needed if the total
+ * transfer size is 32 byte aligned but any of the
+ * sg element lengths are not aligned with 32 byte.
+ */
 #define MCI_ST_DPSM_DMAREQCTL	(1 << 12)
 #define MCI_ST_DPSM_DBOOTMODEEN	(1 << 13)
 #define MCI_ST_DPSM_BUSYMODE	(1 << 14)
-- 
1.7.5.4


^ permalink raw reply related

* [PATCH 1/2] mmc: mmci: Support non-power-of-two block sizes for ux500v2 variant
From: Ulf Hansson @ 2011-10-24 14:33 UTC (permalink / raw)
  To: linux-mmc, linux-arm-kernel
  Cc: Russell King, Ulf Hansson, Lee Jones, Stefan Nilsson XK
In-Reply-To: <1319466800-19884-1-git-send-email-ulf.hansson@stericsson.com>

From: Stefan Nilsson XK <stefan.xk.nilsson@stericsson.com>

For the ux500v2 variant of the PL18x block, non power of two block
sizes are supported. This will make it possible to decrease data
overhead for SDIO transfers.

Signed-off-by: Stefan Nilsson XK <stefan.xk.nilsson@stericsson.com>
Signed-off-by: Ulf Hansson <ulf.hansson@stericsson.com>
---
 drivers/mmc/host/mmci.c |    9 +++++++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 50b5f99..a6387b5 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -53,6 +53,7 @@ static unsigned int fmax = 515633;
  * @sdio: variant supports SDIO
  * @st_clkdiv: true if using a ST-specific clock divider algorithm
  * @blksz_datactrl16: true if Block size is at b16..b30 position in datactrl register
+ * @non_power_of_2_blksize: true if block sizes can be other than power of two
  */
 struct variant_data {
 	unsigned int		clkreg;
@@ -63,6 +64,7 @@ struct variant_data {
 	bool			sdio;
 	bool			st_clkdiv;
 	bool			blksz_datactrl16;
+	bool			non_power_of_2_blksize;
 };
 
 static struct variant_data variant_arm = {
@@ -104,6 +106,7 @@ static struct variant_data variant_ux500v2 = {
 	.sdio			= true,
 	.st_clkdiv		= true,
 	.blksz_datactrl16	= true,
+	.non_power_of_2_blksize	= true,
 };
 
 /*
@@ -594,7 +597,6 @@ static void mmci_start_data(struct mmci_host *host, struct mmc_data *data)
 	writel(host->size, base + MMCIDATALENGTH);
 
 	blksz_bits = ffs(data->blksz) - 1;
-	BUG_ON(1 << blksz_bits != data->blksz);
 
 	if (variant->blksz_datactrl16)
 		datactrl = MCI_DPSM_ENABLE | (data->blksz << 16);
@@ -974,11 +976,14 @@ static irqreturn_t mmci_irq(int irq, void *dev_id)
 static void mmci_request(struct mmc_host *mmc, struct mmc_request *mrq)
 {
 	struct mmci_host *host = mmc_priv(mmc);
+	struct variant_data *variant = host->variant;
 	unsigned long flags;
 
 	WARN_ON(host->mrq != NULL);
 
-	if (mrq->data && !is_power_of_2(mrq->data->blksz)) {
+	if (mrq->data &&
+	    !variant->non_power_of_2_blksize &&
+	    !is_power_of_2(mrq->data->blksz)) {
 		dev_err(mmc_dev(mmc), "unsupported block size (%d bytes)\n",
 			mrq->data->blksz);
 		mrq->cmd->error = -EINVAL;
-- 
1.7.5.4


^ permalink raw reply related

* Re: [PATCH] bnx2x: Adding FW 7.0.29.0
From: David Woodhouse @ 2011-10-24 14:33 UTC (permalink / raw)
  To: dmitry; +Cc: ben@decadent.org.uk, netdev@vger.kernel.org, Eilon Greenstein
In-Reply-To: <1319464676.6155.3.camel@lb-tlvb-dmitry>

[-- Attachment #1: Type: text/plain, Size: 1088 bytes --]

On Mon, 2011-10-24 at 15:57 +0200, Dmitry Kravkov wrote:
> On Mon, 2011-10-17 at 09:12 -0700, Dmitry Kravkov wrote:
> > On Mon, 2011-10-17 at 07:00 -0700, Dmitry Kravkov wrote:
> > > Includes fixes for the following issues:
> > >   1. (iSCSI) Arrival of un-solicited ASYNC message causes
> > >      firmware to abort the connection with RST.
> > >   2. (FCoE) There is a probability that truncated FCoE packet on
> > >      RX path won't get detected which might lead to FW assert.
> > >   3. (iSCSI) Arrival of target-initiated NOP-IN during intense
> > >      ISCSI traffic might lead to FW assert.
> > >   4. (iSCSI) Chip hangs when in case of retransmission not aligned
> > >      to 4-bytes from the beginning of iSCSI PDU.
> > >   5. (FCoE) Arrival of packets beyond task IO size can lead to crash.
> > > 
> 
> David, do you have estimation to handle the request? We have pending
> patch for net-next. Thanks.

Pushed to git.infradead.org; thanks. I'll work on getting the tree back
onto git.kernel.org now I'm sitting at a table with the admin...

-- 
dwmw2

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5818 bytes --]

^ permalink raw reply

* [PATCH 2/2] mmc: mmci: add constraints on alignment for SDIO
From: Ulf Hansson @ 2011-10-24 14:33 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1319466800-19884-1-git-send-email-ulf.hansson@stericsson.com>

From: Per Forlin <per.forlin@stericsson.com>

Buffers must be 4 bytes aligned due to restrictions that
the PL18x FIFO accesses must be done in a 4-byte aligned manner.
Enable DMA_REQCTL for SDIO to support write of not 32 bytes aligned
sg element lengths. In PIO mode any buffer length can be handled
as long as the buffer address is 4 byte aligned.

Signed-off-by: Ulf Hansson <ulf.hansson@stericsson.com>
Signed-off-by: Per Forlin <per.forlin@stericsson.com>
Signed-off-by: Stefan Nilsson XK <stefan.xk.nilsson@stericsson.com>
---
 drivers/mmc/host/mmci.c |   55 +++++++++++++++++++++++++++++++++++++++-------
 drivers/mmc/host/mmci.h |    7 ++++++
 2 files changed, 53 insertions(+), 9 deletions(-)

diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index a6387b5..1a46084 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -45,6 +45,7 @@ static unsigned int fmax = 515633;
  * struct variant_data - MMCI variant-specific quirks
  * @clkreg: default value for MCICLOCK register
  * @clkreg_enable: enable value for MMCICLOCK register
+ * @dma_sdio_req_ctrl: enable value for DMAREQCTL register for SDIO write
  * @datalength_bits: number of bits in the MMCIDATALENGTH register
  * @fifosize: number of bytes that can be written when MMCI_TXFIFOEMPTY
  *	      is asserted (likewise for RX)
@@ -58,6 +59,7 @@ static unsigned int fmax = 515633;
 struct variant_data {
 	unsigned int		clkreg;
 	unsigned int		clkreg_enable;
+	unsigned int		dma_sdio_req_ctrl;
 	unsigned int		datalength_bits;
 	unsigned int		fifosize;
 	unsigned int		fifohalfsize;
@@ -92,6 +94,7 @@ static struct variant_data variant_ux500 = {
 	.fifohalfsize		= 8 * 4,
 	.clkreg			= MCI_CLK_ENABLE,
 	.clkreg_enable		= MCI_ST_UX500_HWFCEN,
+	.dma_sdio_req_ctrl	= MCI_ST_DPSM_DMAREQCTL,
 	.datalength_bits	= 24,
 	.sdio			= true,
 	.st_clkdiv		= true,
@@ -102,6 +105,7 @@ static struct variant_data variant_ux500v2 = {
 	.fifohalfsize		= 8 * 4,
 	.clkreg			= MCI_CLK_ENABLE,
 	.clkreg_enable		= MCI_ST_UX500_HWFCEN,
+	.dma_sdio_req_ctrl	= MCI_ST_DPSM_DMAREQCTL,
 	.datalength_bits	= 24,
 	.sdio			= true,
 	.st_clkdiv		= true,
@@ -110,6 +114,31 @@ static struct variant_data variant_ux500v2 = {
 };
 
 /*
+ * Validate mmc prerequisites
+ */
+static int mmci_validate_data(struct mmci_host *host,
+			      struct mmc_data *data)
+{
+	if (!data)
+		return 0;
+
+	if (!host->variant->non_power_of_2_blksize &&
+	    !is_power_of_2(data->blksz)) {
+		dev_err(mmc_dev(host->mmc),
+			"unsupported block size (%d bytes)\n", data->blksz);
+		return -EINVAL;
+	}
+
+	if (data->sg->offset & 3) {
+		dev_err(mmc_dev(host->mmc),
+			"unsupported alginment (0x%x)\n", data->sg->offset);
+		return -EINVAL;
+	}
+
+	return 0;
+}
+
+/*
  * This must be called with host->lock held
  */
 static void mmci_set_clkreg(struct mmci_host *host, unsigned int desired)
@@ -401,8 +430,12 @@ static int mmci_dma_prep_data(struct mmci_host *host, struct mmc_data *data,
 	if (!chan)
 		return -EINVAL;
 
-	/* If less than or equal to the fifo size, don't bother with DMA */
-	if (data->blksz * data->blocks <= variant->fifosize)
+	/*
+	 * If less than or equal to the fifo size, don't bother with DMA
+	 * SDIO transfers may not be 4 bytes aligned, fall back to PIO
+	 */
+	if (data->blksz * data->blocks <= variant->fifosize ||
+	    (data->blksz * data->blocks) & 3)
 		return -EINVAL;
 
 	device = chan->device;
@@ -437,6 +470,7 @@ static int mmci_dma_start_data(struct mmci_host *host, unsigned int datactrl)
 {
 	int ret;
 	struct mmc_data *data = host->data;
+	struct variant_data *variant = host->variant;
 
 	ret = mmci_dma_prep_data(host, host->data, NULL);
 	if (ret)
@@ -451,6 +485,11 @@ static int mmci_dma_start_data(struct mmci_host *host, unsigned int datactrl)
 
 	datactrl |= MCI_DPSM_DMAENABLE;
 
+	/* Some hardware versions need special flags for SDIO DMA write */
+	if (variant->sdio && host->mmc->card && mmc_card_sdio(host->mmc->card)
+	    && (data->flags & MMC_DATA_WRITE))
+		datactrl |= variant->dma_sdio_req_ctrl;
+
 	/* Trigger the DMA transfer */
 	writel(datactrl, host->base + MMCIDATACTRL);
 
@@ -495,6 +534,9 @@ static void mmci_pre_request(struct mmc_host *mmc, struct mmc_request *mrq,
 	if (!data)
 		return;
 
+	if (mmci_validate_data(host, mrq->data))
+		return;
+
 	if (data->host_cookie) {
 		data->host_cookie = 0;
 		return;
@@ -976,17 +1018,12 @@ static irqreturn_t mmci_irq(int irq, void *dev_id)
 static void mmci_request(struct mmc_host *mmc, struct mmc_request *mrq)
 {
 	struct mmci_host *host = mmc_priv(mmc);
-	struct variant_data *variant = host->variant;
 	unsigned long flags;
 
 	WARN_ON(host->mrq != NULL);
 
-	if (mrq->data &&
-	    !variant->non_power_of_2_blksize &&
-	    !is_power_of_2(mrq->data->blksz)) {
-		dev_err(mmc_dev(mmc), "unsupported block size (%d bytes)\n",
-			mrq->data->blksz);
-		mrq->cmd->error = -EINVAL;
+	mrq->cmd->error = mmci_validate_data(host, mrq->data);
+	if (mrq->cmd->error) {
 		mmc_request_done(mmc, mrq);
 		return;
 	}
diff --git a/drivers/mmc/host/mmci.h b/drivers/mmc/host/mmci.h
index 79e4143..d2737f0 100644
--- a/drivers/mmc/host/mmci.h
+++ b/drivers/mmc/host/mmci.h
@@ -70,6 +70,13 @@
 #define MCI_ST_DPSM_RWMOD	(1 << 10)
 #define MCI_ST_DPSM_SDIOEN	(1 << 11)
 /* Control register extensions in the ST Micro Ux500 versions */
+/*
+ * DMA request control is required for write
+ * if transfer size is not 32 byte aligned.
+ * DMA request control is also needed if the total
+ * transfer size is 32 byte aligned but any of the
+ * sg element lengths are not aligned with 32 byte.
+ */
 #define MCI_ST_DPSM_DMAREQCTL	(1 << 12)
 #define MCI_ST_DPSM_DBOOTMODEEN	(1 << 13)
 #define MCI_ST_DPSM_BUSYMODE	(1 << 14)
-- 
1.7.5.4

^ permalink raw reply related

* [PATCH 1/2] mmc: mmci: Support non-power-of-two block sizes for ux500v2 variant
From: Ulf Hansson @ 2011-10-24 14:33 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <1319466800-19884-1-git-send-email-ulf.hansson@stericsson.com>

From: Stefan Nilsson XK <stefan.xk.nilsson@stericsson.com>

For the ux500v2 variant of the PL18x block, non power of two block
sizes are supported. This will make it possible to decrease data
overhead for SDIO transfers.

Signed-off-by: Stefan Nilsson XK <stefan.xk.nilsson@stericsson.com>
Signed-off-by: Ulf Hansson <ulf.hansson@stericsson.com>
---
 drivers/mmc/host/mmci.c |    9 +++++++--
 1 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 50b5f99..a6387b5 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -53,6 +53,7 @@ static unsigned int fmax = 515633;
  * @sdio: variant supports SDIO
  * @st_clkdiv: true if using a ST-specific clock divider algorithm
  * @blksz_datactrl16: true if Block size is at b16..b30 position in datactrl register
+ * @non_power_of_2_blksize: true if block sizes can be other than power of two
  */
 struct variant_data {
 	unsigned int		clkreg;
@@ -63,6 +64,7 @@ struct variant_data {
 	bool			sdio;
 	bool			st_clkdiv;
 	bool			blksz_datactrl16;
+	bool			non_power_of_2_blksize;
 };
 
 static struct variant_data variant_arm = {
@@ -104,6 +106,7 @@ static struct variant_data variant_ux500v2 = {
 	.sdio			= true,
 	.st_clkdiv		= true,
 	.blksz_datactrl16	= true,
+	.non_power_of_2_blksize	= true,
 };
 
 /*
@@ -594,7 +597,6 @@ static void mmci_start_data(struct mmci_host *host, struct mmc_data *data)
 	writel(host->size, base + MMCIDATALENGTH);
 
 	blksz_bits = ffs(data->blksz) - 1;
-	BUG_ON(1 << blksz_bits != data->blksz);
 
 	if (variant->blksz_datactrl16)
 		datactrl = MCI_DPSM_ENABLE | (data->blksz << 16);
@@ -974,11 +976,14 @@ static irqreturn_t mmci_irq(int irq, void *dev_id)
 static void mmci_request(struct mmc_host *mmc, struct mmc_request *mrq)
 {
 	struct mmci_host *host = mmc_priv(mmc);
+	struct variant_data *variant = host->variant;
 	unsigned long flags;
 
 	WARN_ON(host->mrq != NULL);
 
-	if (mrq->data && !is_power_of_2(mrq->data->blksz)) {
+	if (mrq->data &&
+	    !variant->non_power_of_2_blksize &&
+	    !is_power_of_2(mrq->data->blksz)) {
 		dev_err(mmc_dev(mmc), "unsupported block size (%d bytes)\n",
 			mrq->data->blksz);
 		mrq->cmd->error = -EINVAL;
-- 
1.7.5.4

^ permalink raw reply related

* [PATCH 0/2] mmc: mmci: Improvements for SDIO
From: Ulf Hansson @ 2011-10-24 14:33 UTC (permalink / raw)
  To: linux-arm-kernel

For the ux500v2 variant of the PL18x block, non power of two block
sizes are now supported.

In addition constraints on buffer alignments is needed since access to the
PL18x FIFO must be done on a 4-byte aligned manner. Moreover to be able to
use DMA for buffers with not 32 bytes aligned sg element lengths, DMAREQCTL
must enabled.

Per Forlin (1):
  mmc: mmci: add constraints on alignment for SDIO

Stefan Nilsson XK (1):
  mmc: mmci: Support non-power-of-two block sizes for ux500v2 variant

 drivers/mmc/host/mmci.c |   56 +++++++++++++++++++++++++++++++++++++++++------
 drivers/mmc/host/mmci.h |    7 ++++++
 2 files changed, 56 insertions(+), 7 deletions(-)

-- 
1.7.5.4

^ permalink raw reply

* [PATCH] Shrink thread_info a bit
From: Tim Bird @ 2011-10-24 14:33 UTC (permalink / raw)
  To: linux-arm-kernel
In-Reply-To: <20111024124818.GA17693@n2100.arm.linux.org.uk>

On 10/24/2011 5:48 AM, Russell King - ARM Linux wrote:
> Thread info comes in on Versatile Express at 752 bytes in size, which
> is quite large.  Of this, the crunch state is 184 bytes, which is only
> used on Cirrus Logic devices.
>
> It is wasteful to have this in every kernel when Cirrus Logic CPUs
> are not that widely used.  So make this conditional.
>
> Signed-off-by: Russell King<rmk+kernel@arm.linux.org.uk>
> ---
>   arch/arm/include/asm/thread_info.h |    2 ++
>   arch/arm/kernel/asm-offsets.c      |    2 ++
>   2 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/include/asm/thread_info.h b/arch/arm/include/asm/thread_info.h
> index 7b5cc8d..a030be7 100644
> --- a/arch/arm/include/asm/thread_info.h
> +++ b/arch/arm/include/asm/thread_info.h
> @@ -59,7 +59,9 @@ struct thread_info {
>   	__u32			syscall;	/* syscall number */
>   	__u8			used_cp[16];	/* thread used copro */
>   	unsigned long		tp_value;
> +#ifdef CONFIG_CRUNCH
>   	struct crunch_state	crunchstate;
> +#endif
>   	union fp_state		fpstate __attribute__((aligned(8)));
>   	union vfp_state		vfpstate;
>   #ifdef CONFIG_ARM_THUMBEE
>
>
Since the asm-offsets.h code already has the offset definitions under
#ifdef CONFIG_CRUNCH, this qualifies as a code consistency cleanup,
as well as a memory savings.

I looked at this, and can find no code outside of #ifdef CONFIG_CRUNCH
that references this - so FWIW
Reviewed-by Tim Bird <tim.bird@am.sony.com>

  -- Tim

^ permalink raw reply

* Re: [PATCH V3 1/2] ARM: at91: dt: at91sam9g45 family and board device tree files
From: Nicolas Ferre @ 2011-10-24 14:32 UTC (permalink / raw)
  To: Baruch Siach
  Cc: robherring2, grant.likely, devicetree-discuss, plagnioj,
	linux-kernel, linux-arm-kernel
In-Reply-To: <20111024141253.GF26649@sapphire.tkos.co.il>

On 10/24/2011 04:12 PM, Baruch Siach :
> Hi Nicolas,
> 
> On Mon, Oct 24, 2011 at 04:05:00PM +0200, Nicolas Ferre wrote:
>> Create a new device tree source file for Atmel at91sam9g45 SoC family.
>> The Evaluation Kit at91sam9m10g45ek includes it.
>> This first basic support will be populated as drivers and boards will be
>> converted to device tree.
>> Contains serial, dma and interrupt controllers.
>>
>> The generic board file still takes advantage of platform data for early serial
>> init. As we need a storage media and the NAND flash driver is not converted to
>> DT yet, we keep old initialization for it.
>>
>> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
>> ---
> 
> [snip]
> 
>> +DT_MACHINE_START(at91sam9m10g45ek_dt, "Atmel AT91SAM (Device Tree)")
> 
> Since this is a generic AT91 machine descriptor, won't "at91sam_dt" be a more 
> appropriate name?

For sure that makes sense. I queue this change and make it appear only
in the pull request if it is the only change requested.

>> +	/* Maintainer: Atmel */
>> +	.timer		= &at91sam926x_timer,
>> +	.map_io		= at91_map_io,
>> +	.init_early	= ek_init_early,
>> +	.init_irq	= at91_dt_init_irq,
>> +	.init_machine	= at91_dt_device_init,
>> +	.dt_compat	= at91_dt_board_compat,
>> +MACHINE_END
> 
> baruch

Thanks for your review,

Best regards,
-- 
Nicolas Ferre

^ permalink raw reply


This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.