On 12/18/2012 06:55 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 20:47 Mon 17 Dec , Wolfgang Grandegger wrote:
>> On 12/17/2012 07:02 PM, Roland Stigge wrote:
>>> On 12/17/2012 06:37 PM, Wolfgang Grandegger wrote:
>>>>/* Do synchronous data out
On 12/17/2012 10:33 PM, Roland Stigge wrote:
> On 17/12/12 20:47, Wolfgang Grandegger wrote:
>> On 12/17/2012 07:02 PM, Roland Stigge wrote:
>>> On 12/17/2012 06:37 PM, Wolfgang Grandegger wrote:
>>>>/* Do synchronous data output with a single write access */
&
On 12/17/2012 07:02 PM, Roland Stigge wrote:
> On 12/17/2012 06:37 PM, Wolfgang Grandegger wrote:
>> /* Do synchronous data output with a single write access */
>> __raw_writel(~mask, pio + PIO_OWDR);
>> __raw_writel(mask, pio + PIO_OWER);
>> __raw
On 12/17/2012 06:15 PM, Roland Stigge wrote:
> On 12/17/2012 05:28 PM, Wolfgang Grandegger wrote:
>> On 12/17/2012 02:51 PM, Roland Stigge wrote:
>>> Hi Wolfgang,
>>>> And I guess Russell is right: If possible, we should write outputs
>>>> simultaneou
On 12/17/2012 02:51 PM, Roland Stigge wrote:
> Hi Wolfgang,
>
> On 12/17/2012 02:32 PM, Roland Stigge wrote:
>> And I guess Russell is right: If possible, we should write outputs
>> simultaneously via ODSR (plus OWER/OWDR/OWSR) instead of separate set/clear.
>>
>> I wonder if we need to
On 12/17/2012 01:10 PM, Russell King - ARM Linux wrote:
> On Mon, Dec 17, 2012 at 12:51:32PM +0100, Wolfgang Grandegger wrote:
>> +static void at91_gpiolib_set_block(struct gpio_chip *chip, unsigned long
>> mask, unsigned long val)
>> +{
>> +struc
On 12/17/2012 12:37 PM, Wolfgang Grandegger wrote:
> Hi Roland,
>
> On 12/15/2012 12:49 AM, Roland Stigge wrote:
>> Hi Wolfgang,
>>
>> thank you for the patch!
>>
>> On 14/12/12 18:58, Wolfgang Grandegger wrote:
>>> +static void at91_gpiolib
Hi Roland,
On 12/15/2012 12:49 AM, Roland Stigge wrote:
> Hi Wolfgang,
>
> thank you for the patch!
>
> On 14/12/12 18:58, Wolfgang Grandegger wrote:
>> +static void at91_gpiolib_set_block(struct gpio_chip *chip, unsigned long
>> mask, unsigned long val)
>>
On 12/17/2012 06:15 PM, Roland Stigge wrote:
On 12/17/2012 05:28 PM, Wolfgang Grandegger wrote:
On 12/17/2012 02:51 PM, Roland Stigge wrote:
Hi Wolfgang,
And I guess Russell is right: If possible, we should write outputs
simultaneously via ODSR (plus OWER/OWDR/OWSR) instead of separate
set
On 12/17/2012 07:02 PM, Roland Stigge wrote:
On 12/17/2012 06:37 PM, Wolfgang Grandegger wrote:
/* Do synchronous data output with a single write access */
__raw_writel(~mask, pio + PIO_OWDR);
__raw_writel(mask, pio + PIO_OWER);
__raw_writel(val, pio + PIO_ODSR
On 12/17/2012 10:33 PM, Roland Stigge wrote:
On 17/12/12 20:47, Wolfgang Grandegger wrote:
On 12/17/2012 07:02 PM, Roland Stigge wrote:
On 12/17/2012 06:37 PM, Wolfgang Grandegger wrote:
/* Do synchronous data output with a single write access */
__raw_writel(~mask, pio + PIO_OWDR
On 12/18/2012 06:55 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 20:47 Mon 17 Dec , Wolfgang Grandegger wrote:
On 12/17/2012 07:02 PM, Roland Stigge wrote:
On 12/17/2012 06:37 PM, Wolfgang Grandegger wrote:
/* Do synchronous data output with a single write access */
__raw_writel
Hi Roland,
On 12/15/2012 12:49 AM, Roland Stigge wrote:
Hi Wolfgang,
thank you for the patch!
On 14/12/12 18:58, Wolfgang Grandegger wrote:
+static void at91_gpiolib_set_block(struct gpio_chip *chip, unsigned long
mask, unsigned long val)
+{
+struct at91_gpio_chip *at91_gpio
On 12/17/2012 12:37 PM, Wolfgang Grandegger wrote:
Hi Roland,
On 12/15/2012 12:49 AM, Roland Stigge wrote:
Hi Wolfgang,
thank you for the patch!
On 14/12/12 18:58, Wolfgang Grandegger wrote:
+static void at91_gpiolib_set_block(struct gpio_chip *chip, unsigned long
mask, unsigned long
On 12/17/2012 01:10 PM, Russell King - ARM Linux wrote:
On Mon, Dec 17, 2012 at 12:51:32PM +0100, Wolfgang Grandegger wrote:
+static void at91_gpiolib_set_block(struct gpio_chip *chip, unsigned long
mask, unsigned long val)
+{
+struct at91_gpio_chip *at91_gpio = to_at91_gpio_chip(chip
On 12/17/2012 02:51 PM, Roland Stigge wrote:
Hi Wolfgang,
On 12/17/2012 02:32 PM, Roland Stigge wrote:
And I guess Russell is right: If possible, we should write outputs
simultaneously via ODSR (plus OWER/OWDR/OWSR) instead of separate set/clear.
I wonder if we need to save/restore the
via DT
> * Example implementations in several gpio drivers since they need
> special accessor functions for block wise GPIO access
> * Fix for race condition in gpiolib on device creation
>
> Signed-off-by: Roland Stigge
> Tested by: Wolfgang Grandegger
I'm going to re-test
implementations in several gpio drivers since they need
special accessor functions for block wise GPIO access
* Fix for race condition in gpiolib on device creation
Signed-off-by: Roland Stigge sti...@antcom.de
Tested by: Wolfgang Grandegger w...@grandegger.com
I'm going to re-test this version
On 12/05/2012 11:20 PM, Roland Stigge wrote:
> Hi Wolfgang,
>
> On 05/12/12 20:01, Wolfgang Grandegger wrote:
>>> + for (i = 0; i < block->ngpio; i++) {
>>> + status = gpio_request(block->gpio[i], "gpioblock dev");
>>
On 12/04/2012 09:39 PM, Roland Stigge wrote:
> This patch adds a character device interface to the block GPIO system.
>
> Signed-off-by: Roland Stigge
> ---
> Documentation/ABI/testing/dev-gpioblock | 34 +
> drivers/gpio/gpiolib.c | 208
>
Hi Roland,
On 12/04/2012 09:39 PM, Roland Stigge wrote:
> Hi Wolfgang,
>
> On 03/12/12 10:17, Wolfgang Grandegger wrote:
>> I re-tried v8 on my AT91-SAM9G45 board and it works fine if
>> CONFIG_GPIO_SYSFS is enable. Unfortunately, the access via misc device
>>
Hi Roland,
On 12/04/2012 09:39 PM, Roland Stigge wrote:
Hi Wolfgang,
On 03/12/12 10:17, Wolfgang Grandegger wrote:
I re-tried v8 on my AT91-SAM9G45 board and it works fine if
CONFIG_GPIO_SYSFS is enable. Unfortunately, the access via misc device
fails if CONFIG_GPIO_SYSFS is not set
On 12/04/2012 09:39 PM, Roland Stigge wrote:
This patch adds a character device interface to the block GPIO system.
Signed-off-by: Roland Stigge sti...@antcom.de
---
Documentation/ABI/testing/dev-gpioblock | 34 +
drivers/gpio/gpiolib.c | 208
On 12/05/2012 11:20 PM, Roland Stigge wrote:
Hi Wolfgang,
On 05/12/12 20:01, Wolfgang Grandegger wrote:
+ for (i = 0; i block-ngpio; i++) {
+ status = gpio_request(block-gpio[i], gpioblock dev);
You could use the name of the GPIO block.
OK.
+ if (status
* Added functions for GPIO block registration
> * Added more error checking
> * Bit remapping bugfix
>
> Changes since v1:
> * API change to 32/64 bit word, bit masks
>
> Thanks to Ryan Mallon, Linus Walleij, Stijn Devriendt, Jean-Christophe
> Plagniol-Villard, Mark Brown, G
Plagniol-Villard, Mark Brown, Greg Kroah-Hartman, Grant Likely, Stefan
Roese and Wolfgang Grandegger for reviewing!
I re-tried v8 on my AT91-SAM9G45 board and it works fine if
CONFIG_GPIO_SYSFS is enable. Unfortunately, the access via misc device
fails if CONFIG_GPIO_SYSFS is not set. That's due
ow.
>
> Thanks,
The above two lines should go ...
> Signed-off-by: Muhammad Ghias
> ---
... here (out of the commit message).
Apart from that the patch looks good. You can add my
Acked-by: Wolfgang Grandegger
Thanks for your contribution.
Wolfgang.
--
To unsubscribe fr
,
The above two lines should go ...
Signed-off-by: Muhammad Ghias mgh...@connecttech.com
---
... here (out of the commit message).
Apart from that the patch looks good. You can add my
Acked-by: Wolfgang Grandegger w...@grandegger.com
Thanks for your contribution.
Wolfgang.
--
To unsubscribe from
Hello,
I would like to define trace events for functions without arguments,
e.g. my_yield(). But TRACE_EVENT requires at least one argument to be
defined and I also have not found an example in the kernel sources,
apart from:
$ cat include/trace/events/xen.h
...
Hello,
I would like to define trace events for functions without arguments,
e.g. my_yield(). But TRACE_EVENT requires at least one argument to be
defined and I also have not found an example in the kernel sources,
apart from:
$ cat include/trace/events/xen.h
...
hould call can_led_init(), can_led_exit() and
> can_led_event() as needed.
>
> Supported events are:
> - CAN_LED_EVENT_OPEN: turn on tx/rx LEDs
> - CAN_LED_EVENT_STOP: turn off tx/rx LEDs
> - CAN_LED_EVENT_TX: trigger tx LED blink
> - CAN_LED_EVENT_RX: trigger tx LED blink
>
() and
can_led_event() as needed.
Supported events are:
- CAN_LED_EVENT_OPEN: turn on tx/rx LEDs
- CAN_LED_EVENT_STOP: turn off tx/rx LEDs
- CAN_LED_EVENT_TX: trigger tx LED blink
- CAN_LED_EVENT_RX: trigger tx LED blink
Cc: Oliver Hartkopp socket...@hartkopp.net
Cc: Wolfgang Grandegger w
Paul E. McKenney wrote:
> On Wed, Jan 30, 2008 at 11:45:01AM +0100, Wolfgang Grandegger wrote:
>> Paul E. McKenney wrote:
>>> On Wed, Jan 30, 2008 at 09:18:49AM +0100, Wolfgang Grandegger wrote:
>>>> Paul E. McKenney wrote:
>>>>> On Tue, Jan 29, 2008 a
Paul E. McKenney wrote:
> On Wed, Jan 30, 2008 at 09:18:49AM +0100, Wolfgang Grandegger wrote:
>> Paul E. McKenney wrote:
>>> On Tue, Jan 29, 2008 at 02:38:04PM +0100, Wolfgang Grandegger wrote:
>>>> Luotao Fu wrote:
>>>>> Hi,
>>>>>
>
Paul E. McKenney wrote:
> On Tue, Jan 29, 2008 at 02:38:04PM +0100, Wolfgang Grandegger wrote:
>> Luotao Fu wrote:
>>> Hi,
>>>
>>> Wolfgang Grandegger wrote:
>>> ..
>>>> Do you still get high latencies with:
>>
Paul E. McKenney wrote:
On Tue, Jan 29, 2008 at 02:38:04PM +0100, Wolfgang Grandegger wrote:
Luotao Fu wrote:
Hi,
Wolfgang Grandegger wrote:
..
Do you still get high latencies with:
CONFIG_PREEMPT_RCU_BOOST=y
CONFIG_RCU_TRACE=y
CONFIG_NO_HZ is not set
With this setting I
Paul E. McKenney wrote:
On Wed, Jan 30, 2008 at 11:45:01AM +0100, Wolfgang Grandegger wrote:
Paul E. McKenney wrote:
On Wed, Jan 30, 2008 at 09:18:49AM +0100, Wolfgang Grandegger wrote:
Paul E. McKenney wrote:
On Tue, Jan 29, 2008 at 02:38:04PM +0100, Wolfgang Grandegger wrote:
Luotao Fu
Paul E. McKenney wrote:
On Wed, Jan 30, 2008 at 09:18:49AM +0100, Wolfgang Grandegger wrote:
Paul E. McKenney wrote:
On Tue, Jan 29, 2008 at 02:38:04PM +0100, Wolfgang Grandegger wrote:
Luotao Fu wrote:
Hi,
Wolfgang Grandegger wrote:
..
Do you still get high latencies
Luotao Fu wrote:
> Hi,
>
> Wolfgang Grandegger wrote:
> ..
>> Do you still get high latencies with:
>>
>> CONFIG_PREEMPT_RCU_BOOST=y
>> CONFIG_RCU_TRACE=y
>> CONFIG_NO_HZ is not set
>>
>> With this setting I have not yet realize
Luotao Fu wrote:
Hi,
Wolfgang Grandegger wrote:
..
Do you still get high latencies with:
CONFIG_PREEMPT_RCU_BOOST=y
CONFIG_RCU_TRACE=y
CONFIG_NO_HZ is not set
With this setting I have not yet realized latencies 150us. Could you
please give it a try? If I change one
Hi Fu,
Luotao Fu wrote:
> Hi,
>
> I took some time today and went through Wolfgangs scenarios partly. Now
> some results from my side. I ran my tests on a 2.6.24-rt1
>
> Wolfgang Grandegger wrote:
> > I also did some more measurements and made, by chance, intere
Hi Fu,
Luotao Fu wrote:
Hi,
I took some time today and went through Wolfgangs scenarios partly. Now
some results from my side. I ran my tests on a 2.6.24-rt1
Wolfgang Grandegger wrote:
I also did some more measurements and made, by chance, interesting
observations. I will summarize
Wolfgang Grandegger wrote:
> Hi Fu,
>
> Luotao Fu wrote:
>> Hi folks,
>>
>> On Thu, Jan 17, 2008 at 11:13:26AM +0100, Wolfgang Grandegger wrote:
>>> It builds and runs fine on my Icecube-MPC5200 board, now also with the
>>> latency tracer enabled. Th
Wolfgang Grandegger wrote:
Hi Fu,
Luotao Fu wrote:
Hi folks,
On Thu, Jan 17, 2008 at 11:13:26AM +0100, Wolfgang Grandegger wrote:
It builds and runs fine on my Icecube-MPC5200 board, now also with the
latency tracer enabled. That's great. Still, cyclictest -n -p80 -i1000
reports
Hi Fu,
Luotao Fu wrote:
> Hi folks,
>
> On Thu, Jan 17, 2008 at 11:13:26AM +0100, Wolfgang Grandegger wrote:
>> It builds and runs fine on my Icecube-MPC5200 board, now also with the
>> latency tracer enabled. That's great. Still, "cyclictest -n -p80 -i1000"
&g
Hi Fu,
Luotao Fu wrote:
Hi folks,
On Thu, Jan 17, 2008 at 11:13:26AM +0100, Wolfgang Grandegger wrote:
It builds and runs fine on my Icecube-MPC5200 board, now also with the
latency tracer enabled. That's great. Still, cyclictest -n -p80 -i1000
reports latencies up to 400 us and therefore
Robert Schwebel wrote:
> On Thu, Jan 17, 2008 at 11:13:26AM +0100, Wolfgang Grandegger wrote:
>> # ./cyclictest -n -p80 -i1000 -b400
>>
>> [...]
>>
>> Well, I'm not sure if this is the correct way to do it. Is there some
>> doc on how to use the l
Steven Rostedt wrote:
> On Thu, 17 Jan 2008, Daniel Walker wrote:
>
>> On Thu, 2008-01-17 at 19:17 +0100, Wolfgang Grandegger wrote:
>>> [0.733248] TCP bind hash table entries: 2048 (order: 3, 57344
>>> bytes)
>>> [0.741132] TCP: Hash tables con
Daniel Walker wrote:
> On Thu, 2008-01-17 at 19:17 +0100, Wolfgang Grandegger wrote:
>> [0.733248] TCP bind hash table entries: 2048 (order: 3, 57344
>> bytes)
>> [0.741132] TCP: Hash tables configured (established 2048 bind
>> 2048)
>> [0.747981] TCP
Daniel Walker wrote:
> On Thu, 2008-01-17 at 11:13 +0100, Wolfgang Grandegger wrote:
>> Steven Rostedt wrote:
>>> We are pleased to announce the 2.6.24-rc8-rt1 tree, which can be
>>> downloaded from the location:
>>>
>>> http://rt.et.redhat.com/downl
Steven Rostedt wrote:
> We are pleased to announce the 2.6.24-rc8-rt1 tree, which can be
> downloaded from the location:
>
> http://rt.et.redhat.com/download/
It builds and runs fine on my Icecube-MPC5200 board, now also with the
latency tracer enabled. That's great. Still, "cyclictest -n -p80
Daniel Walker wrote:
On Thu, 2008-01-17 at 11:13 +0100, Wolfgang Grandegger wrote:
Steven Rostedt wrote:
We are pleased to announce the 2.6.24-rc8-rt1 tree, which can be
downloaded from the location:
http://rt.et.redhat.com/download/
It builds and runs fine on my Icecube-MPC5200 board
Steven Rostedt wrote:
On Thu, 17 Jan 2008, Daniel Walker wrote:
On Thu, 2008-01-17 at 19:17 +0100, Wolfgang Grandegger wrote:
[0.733248] TCP bind hash table entries: 2048 (order: 3, 57344
bytes)
[0.741132] TCP: Hash tables configured (established 2048 bind
2048)
[0.747981] TCP
Robert Schwebel wrote:
On Thu, Jan 17, 2008 at 11:13:26AM +0100, Wolfgang Grandegger wrote:
# ./cyclictest -n -p80 -i1000 -b400
[...]
Well, I'm not sure if this is the correct way to do it. Is there some
doc on how to use the latency tracer and interpret the results?
Could you put
Thomas Gleixner wrote:
Please do not top post !
On Fri, 2007-05-18 at 11:10 +0300, emin ak wrote:
Yes, 2.6.21 was compiled and boot successfully for ppc, Is 85xx family
supported for powerpc arch?
I don't know. You might ask the folks on the ppc mailing list.
E.g. check
Thomas Gleixner wrote:
Please do not top post !
On Fri, 2007-05-18 at 11:10 +0300, emin ak wrote:
Yes, 2.6.21 was compiled and boot successfully for ppc, Is 85xx family
supported for powerpc arch?
I don't know. You might ask the folks on the ppc mailing list.
E.g. check
101 - 156 of 156 matches
Mail list logo
