On Mon, 2012-11-19 at 11:44 +, Pawel Moll wrote:
> On Thu, 2012-11-08 at 15:35 +0000, Pawel Moll wrote:
> > Hi Bryan, Richard,
> >
> > On Thu, 2012-11-01 at 17:58 +, Pawel Moll wrote:
> > > LEDs are often controlled by writing to memory mapped
&
On Mon, 2012-11-26 at 15:37 +, Vasily Khoruzhick wrote:
> On Thu, Nov 1, 2012 at 8:58 PM, Pawel Moll wrote:
> > LEDs are often controlled by writing to memory mapped
> > register. This patch adds:
> >
> > 1. Generic functions for platform code and drivers to cre
On Wed, 2013-02-06 at 01:19 +, Steven Rostedt wrote:
> If people are worried about adding a bunch of new perf syscalls, maybe
> add a sys_perf_control() system call that works like an ioctl but
> without a file descriptor. Something for things that don't require an
> event attached to it, like
On Tue, 2013-02-05 at 22:13 +, Stephane Eranian wrote:
> The app requesting the timestamp may not necessarily have an active
> perf session. And by that I mean, it may not be self-monitoring. But it
> could be monitored by an external tool such as perf, without necessary
> knowing it.
Fair eno
On Tue, 2013-04-02 at 08:54 +0100, Peter Zijlstra wrote:
> On Mon, 2013-04-01 at 11:29 -0700, John Stultz wrote:
> > I'm still not sold on the CLOCK_PERF posix clock. The semantics are
> > still too hand-wavy and implementation specific.
>
> How about we define the semantics as: match whatever co
On Tue, 2013-04-02 at 17:19 +0100, John Stultz wrote:
> I still think exposing the perf clock to userland is a bad idea, and
> would much rather the kernel provide timestamp data in the logs
> themselves to make the logs useful. But if we're going to have to do
> this via a clockid, I'm going to
The registration of the "leds-gpio" device was using
"vexpress_sysreg_dev" as a parent before it was actually
set to something different than NULL.
Trivial fix by reordering the code.
Reported-by: Lorenzo Pieralisi
Signed-off-by: Pawel Moll
---
drivers/mfd/vexpress-sys
On Tue, 2013-04-02 at 17:19 +0100, John Stultz wrote:
> But if we're going to have to do
> this via a clockid, I'm going to want it to be done via a dynamic posix
> clockid, so its clear its tightly tied with perf and not considered a
> generic interface (and I can clearly point folks having pro
On Wed, 2013-04-03 at 18:29 +0100, John Stultz wrote:
> On 04/03/2013 10:19 AM, Pawel Moll wrote:
> > On Tue, 2013-04-02 at 17:19 +0100, John Stultz wrote:
> >> But if we're going to have to do
> >> this via a clockid, I'm going to want it to be done via a dyn
On Wed, 2013-04-03 at 18:50 +0100, John Stultz wrote:
> I get the reasoning around reusing the fd we already have, but is the
> possibility of a dynamic chardev pathname really a big concern?
Well, in my particular development system I have no udev, so I had to
manually do "mknod". Perf syscall w
On Thu, 2013-04-04 at 08:37 +0100, Richard Cochran wrote:
> > I get the reasoning around reusing the fd we already have, but is
> > the possibility of a dynamic chardev pathname really a big concern?
>
> I have been following this thread, and, not knowing very much about
> perf, I would think that
On Thu, 2013-04-04 at 17:29 +0100, Pawel Moll wrote:
> > Maybe can we extend the dynamic posix clock code to work on more then
> > just the chardev?
>
> The idea I'm following now is to make the dynamic clock framework even
> more generic, so there could be a clock as
The LEDs on the Versatile Express motherboard are controlled
through simple memory-mapped register. This patch extends
the pseudo-GPIO controller definition for these lines and
creates generic "leds-gpio" device using them
Signed-off-by: Pawel Moll
---
Hello Samuel,
Would you be
On Wed, 2013-01-30 at 15:49 +, Samuel Ortiz wrote:
> On Wed, Jan 30, 2013 at 10:33:16AM +0000, Pawel Moll wrote:
> > The LEDs on the Versatile Express motherboard are controlled
> > through simple memory-mapped register. This patch extends
> > the pseudo-GPIO controller
ening a "fake" perf descriptor in
order to get the timestamp, but surely one must have the "session"
already running to be interested in such data in the first place? So I
think the ioctl() idea is not out of place here... How about the simple
change below?
Regards
Pawel
8<---
o
Limits: 0 - 6
Mono: 0 [0%]
Signed-off-by: Pawel Moll
---
include/uapi/linux/usb/audio.h |6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/include/uapi/linux/usb/audio.h b/include/uapi/linux/usb/audio.h
index ac90037..d2314be 100644
--- a/include/uapi/linux/usb/audio.
- below
John also suggested that maybe the perf could use CLOCK_MONOTONIC_RAW
instead of local/sched_clock().
How about a final decision?
Regards
Pawel
8<
>From c986492d38156f1fc25ab3182f0a494bb13389ce Mon Sep 17 00:00:00 2001
From: Pawel Moll
Date: Thu, 14 Mar 20
On Fri, 2012-09-14 at 12:13 +0100, Stefano Stabellini wrote:
> Signed-off-by: Stefano Stabellini
> CC: Russell King
> CC: Pawel Moll
> CC: Marc Zyngier
> ---
> arch/arm/mach-vexpress/v2m.c | 11 ++-
> 1 files changed, 6 insertions(+), 5 deletions(-)
>
>
On Fri, 2012-09-14 at 13:48 +0100, Stefano Stabellini wrote:
> On Fri, 14 Sep 2012, Pawel Moll wrote:
> > On Fri, 2012-09-14 at 12:13 +0100, Stefano Stabellini wrote:
> > > Signed-off-by: Stefano Stabellini
> > > CC: Russell King
> > > CC
Greetings All,
More and more of people are getting interested in the subject of power
(energy) consumption monitoring. We have some external tools like
"battery simulators", energy probes etc., but some targets can measure
their power usage on their own.
Traditionally such data should be exposed
On Tue, 2012-10-23 at 18:43 +0100, Steven Rostedt wrote:
> > <...>212.673126: hwmon_attr_update: hwmon4 temp1_input 34361
> >
> > One issue with this is that some external knowledge is required to
> > relate a number to a processor core. Or maybe it's not an issue at all
> > because it should be l
On Tue, 2012-10-23 at 19:49 +0100, Andy Green wrote:
> A thought on that... from an SoC perspective there are other interesting
> power rails than go to just the CPU core. For example DDR power and
> rails involved with other IP units on the SoC such as 3D graphics unit.
> So tying one number
On Tue, 2012-10-23 at 23:02 +0100, Guenter Roeck wrote:
> > Traditionally such data should be exposed to the user via hwmon sysfs
> > interface, and that's exactly what I did for "my" platform - I have
> > a /sys/class/hwmon/hwmon*/device/energy*_input and this was good
> > enough to draw pretty gr
On Wed, 2012-10-24 at 01:40 +0100, Thomas Renninger wrote:
> > More and more of people are getting interested in the subject of power
> > (energy) consumption monitoring. We have some external tools like
> > "battery simulators", energy probes etc., but some targets can measure
> > their power usag
This patch removes custom code for controlling LEDs on
Versatile Express platform and register MFD cell for
the SYS_LED register for the leds-mmio-simple driver.
Signed-off-by: Pawel Moll
---
drivers/mfd/Kconfig |1 +
drivers/mfd/vexpress-sysreg.c | 125
evexit mmio_simple_leds_remove(struct platform_device *pdev)
+{
+ struct mmio_simple_leds *leds = platform_get_drvdata(pdev);
+ int i;
+
+ platform_set_drvdata(pdev, NULL);
+
+ for (i = 0; i < leds->num_leds; i++)
+ mmio_led_unregister(leds->leds[i]);
+
+
On Mon, 2012-11-05 at 09:39 +, Jon Medhurst (Tixy) wrote:
> > +static void mmio_led_brightness_set(struct led_classdev *cdev,
> > + enum led_brightness brightness)
> > +{
> > + struct mmio_led *led = container_of(cdev, struct mmio_led, cdev);
> > + unsigned long uninitialized_var(
On Mon, 2012-11-05 at 08:21 +, Lee Jones wrote:
> > > processed = sscanf(str, "@%lli:%u%n:%d%n",
> > > - &base, &resources[1].start, &consumed,
> > > + &base, (unsigned int *)&resources[1].start, &consumed,
> > > &vm_cmdline_id, &consumed);
>
to follow.
Reported-by: Lee Jones
Signed-off-by: Pawel Moll
---
drivers/virtio/virtio_mmio.c | 26 ++
1 file changed, 18 insertions(+), 8 deletions(-)
diff --git a/drivers/virtio/virtio_mmio.c b/drivers/virtio/virtio_mmio.c
index 6b1b7e1..0d08843 100644
--- a/driv
On Mon, 2012-11-05 at 13:44 +, Lee Jones wrote:
> On Mon, 05 Nov 2012, Pawel Moll wrote:
>
> > On 64-bit machines resource_size_t is a 64-bit value, while
> > sscanf() format for this argument was defined as "%u". Fixed
> > by using an intermediate local valu
rboard node;
> - set the machine compatible to "xen,xenvm-4.2", "xen,xenvm";
> - rename the dts file to xenvm-4.2.dts;
> - add "xen,xenvm" to the list of compatible DT strings to mach-vexpress.
>
> Signed-off-by: Stefa
Some regulators can set any voltage within the constraints range,
not being limited to specified operating points.
This patch makes it possible to describe such regulator and makes
the regulator_is_supported_voltage() function behave correctly.
Signed-off-by: Pawel Moll
---
drivers/regulator
Implementation of the regulator framework driver for the
Versatile Express voltage control. Devices without
voltage constraints (ie. "regulator-[min|max]-microvolt"
properties in the DT node) are treated as fixed (or rather
read-only) regulators.
Signed-off-by: Pawel Moll
---
.../
and almost
certainly not what one would expect.
This patch moves makes the clean target of the script called
only when !KBUILD_EXTMOD.
Signed-off-by: Pawel Moll
---
Makefile |8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index 5be2ee8..fa16e12 10
On Tue, 2012-10-30 at 10:11 +, Mike Turquette wrote:
> > diff --cc arch/arm/include/asm/hardware/sp810.h
> > index 2cdcf44,afd7e91..000
> > --- a/arch/arm/include/asm/hardware/sp810.h
> > +++ b/arch/arm/include/asm/hardware/sp810.h
> > @@@ -50,6 -50,14 +50,8 @@@
> > #define SCPCELLID2
On Tue, 2013-08-27 at 16:51 +0100, Rob Herring wrote:
> >> * pl111 has no driver or binding in mainline, but appears in dts files.
> >> Those dts files clcdclk and apb_pclk, in that order. We could fix
> >> those before a driver starts using them.
>
> I think this was waiting for some generic
; Signed-off-by: Sebastian Hesselbarth
> Tested-by: Jon Medhurst (Tixy)
Acked-by: Pawel Moll
Thanks!
Pawel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.or
On Thu, 2013-09-05 at 12:30 +0100, Mark Rutland wrote:
> I also note that the device can also be attached to SPI. Do we have any
> other devices which may be attached to either? Do we handle that, and if
> so, how (do we have the same compatible string for both interfaces?)?
Theoretically you don'
On Fri, 2013-08-30 at 09:50 +0100, Ian Campbell wrote:
> Filtering capabilities on my work email are pretty much non-existent and this
> has turned out to be something of a firehose...
Unfortunately I exactly know what you mean...
> Cc: Pawel Moll
> Cc: Mark Rutland
> Cc: Steph
On Fri, 2013-08-30 at 11:02 +0100, Jon Medhurst (Tixy) wrote:
> On Thu, 2013-08-29 at 20:16 +0200, Sebastian Hesselbarth wrote:
> > On 08/29/13 15:35, Arnd Bergmann wrote:
> > > On Tuesday 27 August 2013, Sebastian Hesselbarth wrote:
> > >> @@ -422,16 +419,8 @@ void __init v2m_dt_init_early(void)
>
c);
> - regulator_unregister(reg->regdev);
>
> return 0;
> }
I'm assuming it's following a patch adding devm_regulator_register()?
Based on this:
Acked-by: Pawel Moll
Thanks!
Pawel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel&quo
verything stays in
alphabetical order ;-) you can add my Acked-by for vexpress:
Acked-by: Pawel Moll
Thanks!
Pawel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On Wed, 2012-10-17 at 02:00 +0100, Axel Lin wrote:
> The of_device_id table is supposed to be zero-terminated.
Damn, stupid mistake. Thanks for spotting this!
Pawel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
M
On Wed, 2012-10-17 at 04:26 +0100, Axel Lin wrote:
> I don't have a chance to compile test this patch because I could not
> find VEXPRESS_CONFIG in current tree.
> Can you help testing this patch?
I'll be more than happy to help, but can you please tell me what use
case you have in mind? The "reg-
On Tue, 2012-12-11 at 08:23 +, Axel Lin wrote:
> This fixes below build error:
>
> Building modules, stage 2.
> MODPOST 17 modules
> ERROR: "__vexpress_config_func_get" [drivers/regulator/vexpress.ko] undefined!
> ERROR: "vexpress_config_func_put" [drivers/regulator/vexpress.ko] undefined!
What I believe should
be fixed is the mentioned function itself, something like the patch
below (untested)...
Pawel
8<
>From 1cafb644747c276a6c601096b8dc0972d10daac7 Mon Sep 17 00:00:00 2001
From: Pawel Moll
Date: Tue, 11 Dec 2012 13:44:07 +
Subject
Hi Bryan, Richard,
On Thu, 2012-11-01 at 17:58 +, Pawel Moll wrote:
> LEDs are often controlled by writing to memory mapped
> register. This patch adds:
>
> 1. Generic functions for platform code and drivers to create
>class device for LEDs controlled by arbitrary bit
On Thu, 2012-11-08 at 15:35 +, Pawel Moll wrote:
> Hi Bryan, Richard,
>
> On Thu, 2012-11-01 at 17:58 +0000, Pawel Moll wrote:
> > LEDs are often controlled by writing to memory mapped
> > register. This patch adds:
> >
> > 1. Generic functions for pl
On Fri, 2013-04-19 at 08:27 +0100, Stephen Rothwell wrote:
> Hi Mike,
>
> Today's linux-next merge of the clk tree got a conflict in
> arch/arm/mach-vexpress/v2m.c between commit dabfd8fb84ab ("ARM: vexpress:
> remove sp804 OF init") from the arm-soc tree and commit 6e973d2c4385
> ("clk: vexpress:
On Thu, 2013-06-13 at 01:13 +0100, Samuel Ortiz wrote:
> Now, about the driver itself, besides the really odd code design, the
> static variables all over the place, the nasty init hacks and the
> unneeded long function names, someone should refresh my memory and explain
> to me why is this guy und
On Thu, 2013-06-13 at 23:52 +0100, Olof Johansson wrote:
> > + reg = <0 0x7FFF 0 0x1000>;
>
> #size-cells 2 on the parent bus? That's somewhat unusual.
LPAE == 40 bit physical addresses == potential > 32 bit sizes (memory
blocks > 4GB)
Paweł
--
To unsubscribe from this list: send the
Morning, Samuel,
On Tue, 2013-06-18 at 10:09 +0100, Samuel Ortiz wrote:
> Hi Pawell,
Double l in the wrong place ;-)
> > If you feel strongly about it, I'm ready to split it into mfd_cells and
> > move the gpio and leds code into separate drivers, however I'm not
> > convinced that it's worth th
On Wed, 2013-06-19 at 13:37 +0100, Arnd Bergmann wrote:
> I think when vexpress-sysreg was created, we didn't have the syscon driver
> yet, otherwise I think we should have used that, and put separate
> drivers on top.
>
> Not sure if it's too late for changing it to that now, given that
> we alre
On Wed, 2013-06-19 at 16:03 +0100, Arnd Bergmann wrote:
> On Wednesday 19 June 2013, Pawel Moll wrote:
> > ... but sysreg does more than just that. In particular it provides a
> > pseudo-gpio controller (I don't think you want to hide this behind the
> > syscon) and it
On Mon, 2013-06-10 at 16:12 +0100, Pawel Moll wrote:
> The driver can be used on either arm or arm64 platforms, but
> the latter doesn't have any platform-specific configuration
> options, so it must be possible to manually enable the driver.
>
> Signed-off-by: Pawel Moll
ff-by: Pawel Moll
Acked-by: Catalin Marinas
---
drivers/mfd/Kconfig | 3 ++-
drivers/mfd/vexpress-sysreg.c | 10 --
2 files changed, 10 insertions(+), 3 deletions(-)
Hi Samuel,
Could you please queue this small change for 3.11?
Thanks!
Pawel
diff --git a/drivers/mfd/Kconfig b/dr
The driver can be used on either arm or arm64 platforms, but
the latter doesn't have any platform-specific configuration
options, so it must be possible to manually enable the driver.
Signed-off-by: Pawel Moll
Acked-by: Catalin Marinas
---
drivers/power/reset/Kconfig | 3 ++-
1 file chang
ff-by: Pawel Moll
Acked-by: Catalin Marinas
---
drivers/mfd/Kconfig | 3 ++-
drivers/mfd/vexpress-sysreg.c | 10 --
2 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index d54e985..6959b8d 100644
--- a/drivers/mfd/Kconfig
On Tue, 2013-08-13 at 22:23 +0100, Jonathan Cameron wrote:
> On 07/22/13 15:04, Hector Palacios wrote:
> > Some LRADC channels have fixed pre-dividers so they can measure
> > different voltages at full scale. The reference voltage allows to
> > expose a scaling attribute through the IIO sysfs so th
On Wed, 2013-08-14 at 20:09 +0100, Kumar Gala wrote:
> +Required properties:
> +- compatible: should be "qcom,tcsr-mutex"
> +- reg: Should contain registers location and length of mutex registers
> +- reg-names:
> + "mutex-base" - string to identify mutex registers
Just out of curiosity, why
fined reference to
`__vexpress_config_func_get'
iio-trig-interrupt.c:(.text+0x1aff4c): undefined reference to
`vexpress_config_write'
Added required dependency to the Kconfig entry.
Signed-off-by: Pawel Moll
---
drivers/power/reset/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion
On Fri, 2013-08-16 at 23:54 +0100, Stephen Warren wrote:
> Indeed, I tend to think that reg-names is a bad idea.
>
> IIRC, the rule for "reg" is that entries must always have a defined
> order, so that it can always be accessed by integer index.
First time I hear about that rule, really...
> An
On Wed, 2013-06-26 at 17:49 +0100, David Ahern wrote:
> With all the perf ioctl extensions tossed out the past day or so I
> wanted to revive this request. Still need a solution to the problem of
> correlating perf_clock to other clocks ...
And I second. We've been trying to squeeze the solution
n-existing yet) directory would be the right thing to do?
Other than that:
Acked-by: Pawel Moll
Thanks!
Paweł
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/ma
On Wed, 2013-07-17 at 13:33 +0100, Nicolas Pitre wrote:
> If this is really miscelaneous code that really doesn't fit
> anywhere else, it should rather go into drivers/misc/ as a last resort.
Interestingly enough drivers/misc was my first choice for all the
vexpress stuff, but it wasn't received
On Wed, 2013-07-17 at 15:16 +0100, Nicolas Pitre wrote:
> On Wed, 17 Jul 2013, Pawel Moll wrote:
>
> > On Wed, 2013-07-17 at 13:33 +0100, Nicolas Pitre wrote:
> > > If this is really miscelaneous code that really doesn't fit
> > > anywhere else, it should rat
On Tue, 2013-08-20 at 16:01 +0100, Kumar Gala wrote:
> On Aug 20, 2013, at 9:54 AM, Ivan T. Ivanov wrote:
>
> >
> > Hi,
> >
> > On Tue, 2013-08-20 at 09:33 -0500, Felipe Balbi wrote:
> >> On Tue, Aug 20, 2013 at 05:09:11PM +0300, Ivan T. Ivanov wrote:
> >>> Hi,
> >>>
> >>> On Tue, 2013-08-20
On Tue, 2013-08-20 at 16:06 +0100, Pawel Moll wrote:
> On Tue, 2013-08-20 at 16:01 +0100, Kumar Gala wrote:
> > On Aug 20, 2013, at 9:54 AM, Ivan T. Ivanov wrote:
> >
> > >
> > > Hi,
> > >
> > > On Tue, 2013-08-20 at 09:33 -0500, Felipe Balb
On Wed, 2013-08-21 at 23:13 +0100, Alexandre Belloni wrote:
> You are not so wrong. There is indeed actually only one reference
> voltage (and that is 1.85V). But, before feeding the voltage to the ADC
> channels, you sometimes have a divider. Then, after the channel muxing,
> you can add a by 2 d
On Thu, 2013-08-22 at 09:05 +0100, Hector Palacios wrote:
> This was what I originally submitted but it then looked like it would better
> fit in
> the DeviceTree. The spear-adc seemed to use a similar approach:
I'm not sure if it's the best example... I much more prefer the AD7303's
way:
Docum
On Thu, 2013-08-22 at 07:17 +0100, Jonathan Cameron wrote:
> I would favour option 2 though some of the discussions going on at the moment
> about
> bindings might result in a generic description of this and any other bits of
> analog front end.
Any link to this discussion? devicet...@vger.kerne
Apologies about the delay, I was "otherwise engaged" for a week...
I hope you haven't lost all motivation to work on this subject, as it's
really worth the while!
On Fri, 2013-07-26 at 20:55 +0100, Eduardo Valentin wrote:
> On 25-07-2013 13:33, Pawel Moll wrote:
> >
On Tue, 2013-08-06 at 12:53 +0100, Ivan T. Ivanov wrote:
> From: "Ivan T. Ivanov"
>
> Signed-off-by: Ivan T. Ivanov
I am sure that the information in the subject is more than enough for
you, but would you care to give some more background for the commit log?
Where can we find such controllers?
On Tue, 2013-08-06 at 12:53 +0100, Ivan T. Ivanov wrote:
> From: "Ivan T. Ivanov"
>
> Signed-off-by: Ivan T. Ivanov
The same comment as for the RFC 1/2 here...
> .../devicetree/bindings/usb/msm-ssusb.txt | 39 +
> drivers/usb/dwc3/Kconfig |8 +
> d
On Tue, 2013-08-06 at 14:46 +0100, Ivan T. Ivanov wrote:
> > > + reg = <0xf920 0xcd00>;
> > > + interrupts = <0 131 0>;
> > > + interrupt-names = "irq";
> > > + usb-phy = <&dwc3_usb2>, <&dwc3_usb3>;
> > > + tx-fifo-
On Thu, 2013-08-08 at 09:53 +0100, Mark Rutland wrote:
> On Wed, Aug 07, 2013 at 09:18:29PM +0100, Eduardo Valentin wrote:
> > Pawel, all,
> >
> > On 06-08-2013 07:14, Pawel Moll wrote:
> > > Apologies about the delay, I was "otherwise engaged" for a week
On Thu, 2013-08-08 at 16:51 +0100, Kumar Gala wrote:
> I'm tossing my hat into the ring of maintainers/reviewers for device tree
> bindings based on history of dealing with DT on embedded PPC and starting
> work on ARM SoCs.
>
> Signed-off-by: Kumar Gala
> Cc: Pawel M
On Sat, 2013-07-20 at 04:19 +0100, Grant Likely wrote:
> +F: include/dt-bindings
One thing we didn't finish talking about was the question if this
directory is supposed to contain *.dtsi files as well? The obvious
problem I have is a vexpress motherboard being (well, actually not bein
right now)
On Mon, 2013-07-22 at 21:03 +0100, Rob Herring wrote:
> On 07/22/2013 11:50 AM, Pawel Moll wrote:
> > On Sat, 2013-07-20 at 04:19 +0100, Grant Likely wrote:
> >> +F:include/dt-bindings
> >
> > One thing we didn't finish talking about was the question i
Greeting,
Funnily enough I had this discussion couple a months ago and made my
mind back then :-)
> On 07/22/2013 07:25 AM, Eduardo Valentin wrote:
> > representing in device tree would not
> > infringe the original purpose of this data structure ("The Device
> > Tree is a data structure for des
On Wed, 2013-07-24 at 16:04 +0100, Eduardo Valentin wrote:
> > 1. As you have pointed out, the thermal limits are related to the
> > *device being monitored*, not the sensor itself.
> >
> Yeah, thinking of it now, this original proposal, it lacks a stronger
> relationship mapping between monitored
On Thu, 2013-07-25 at 17:15 +0100, Pawel Moll wrote:
> > Another way, as I mentioned in the original RFC, an option would be to
> > have the thermal_zone node not embedded in any device node. But them, we
> > would need to firmly link it to other device nodes, to describe what is
On Thu, 2013-07-25 at 18:20 +0100, Eduardo Valentin wrote:
> >>thermal_zone {
> >>type = "CPU";
> >
> > So what does this exactly mean? What is so special about CPU? What other
> > types you've got there? (Am I just lazy not looking at the numerous
> > links you provided? ;-)
>
>
On Fri, 2013-03-01 at 10:41 +, Marc Zyngier wrote:
> On 14/02/13 10:54, Pawel Moll wrote:
> > To solve the never-ending confusions between hosts and guests
> > of different endianess, define all virtio-mmio registers as LE.
> >
> > This change should be safe at t
ollows :-)
> Well, it was unclear enough for me to get confused... ;-) It would make
> sense to have a wording similar to the one in the PCI section.
How about this?
8<-
>From a80f01f15397395a8fc49ef424a2d47c8be0937a Mon Sep 17 00:00:00 2001
From: Pawel Moll
Date: Fri, 1 M
On Tue, 2013-03-05 at 00:11 +, Rusty Russell wrote:
> Pawel Moll writes:
> > On Fri, 2013-03-01 at 11:21 +, Marc Zyngier wrote:
> >> > Having said that, Rusty was contemplating enforcing LE config space in
> >> > the new PCI layout...
> >>
>
_dt_init_early,
> - .init_irq = irqchip_init,
> .init_time = v2m_dt_timer_init,
> .init_machine = v2m_dt_init,
> MACHINE_END
Acked-by: Pawel Moll
Thanks!
Pawel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
On Sat, 2013-04-06 at 12:05 +0100, Richard Cochran wrote:
> On Fri, Apr 05, 2013 at 07:16:53PM +0100, Pawel Moll wrote:
> > Ok, so how about the code below? Disclaimer: this is just a proposal.
> > I'm not sure how welcomed would be an extra field in struct file, but
>
On Tue, 2013-04-09 at 12:23 +0100, Linus Walleij wrote:
> On Sun, Apr 7, 2013 at 11:23 PM, Arnd Bergmann wrote:
> > On Sunday 07 April 2013, Daniel Tang wrote:
> >> Here's an updated patch that enables support for the LCD.
> >>
> >> I looked into drivers/video/of_display_timing.c but it doesn't ha
The config transactions "scheduler" was hopelessly broken,
repeating completed transaction instead of picking up
next pending one.
Fixed now. Also improved debug messages.
Signed-off-by: Pawel Moll
---
drivers/mfd/vexpress-config.c | 31 ---
1 file c
On Thu, 2013-04-25 at 14:02 +0100, Jon Medhurst (Tixy) wrote:
> > + while (!list_empty(&bridge->transactions)) {
> > + trans = list_first_entry(&bridge->transactions,
> > + struct vexpress_config_trans, list);
> >
> > - bridge->info->func_exec(trans
The config transactions "scheduler" was hopelessly broken,
repeating completed transaction instead of picking up
next pending one.
Fixed now. Also improved debug messages.
Signed-off-by: Pawel Moll
---
drivers/mfd/vexpress-config.c | 35 +--
1 file c
AFAIK, the clcd
> > driver isn't aware of DT so the only way is to use the AUXDATA right now.
>
> Linus Walleij mentioned on IRC that Pawel Moll already posted a series
> that adds DT support for clcd:
>
> http://lists.freedesktop.org/archives/dri-devel/2013-April/037519.htm
On Mon, 2013-05-27 at 11:32 +0100, Arnd Bergmann wrote:
> b) add a new KMS driver for this hardware that can be used as an
> alternative to the existing one and that works with DT.
There are people working on this, just trying to jump through some legal
hoops to post a RFC. Once this is done we'll
On Tue, 2013-05-28 at 15:16 +0100, Linus Walleij wrote:
> On Tue, May 28, 2013 at 12:54 PM, Pawel Moll wrote:
> > On Mon, 2013-05-27 at 11:32 +0100, Arnd Bergmann wrote:
> >> b) add a new KMS driver for this hardware that can be used as an
> >> alternative to the exist
Morning,
On Wed, 2012-09-19 at 18:44 +0100, Stefano Stabellini wrote:
> +/dts-v1/;
> +
> +/include/ "skeleton.dtsi"
Any particular reason to include skeleton? And I think it would be
better to use #address-cells = <2> and #size-cells = <2>, to be ready
for LPAE addresses...
> +/ {
> + model
On Thu, 2012-09-20 at 12:39 +0100, Stefano Stabellini wrote:
> There are no peripherals apart from the ones that are already described
> here (timer, gic). All the peripherals that the guest sees are virtual
> devices that show up on xenbus (a virtual bus). In order to initialize
> xenbus, the gues
On Thu, 2012-09-20 at 15:11 +0100, Stefano Stabellini wrote:
> On Thu, 20 Sep 2012, Arnd Bergmann wrote:
> > It's not much different in the end, but I think I'd rather make the
> > compatible list in the device tree "xen,xenvm-4.2", "xen,xenvm" without
> > listing "arm,vexpress", but then adding "x
perty is declared in
> of.h which is only included by of_device.h if CONFIG_OF_DEVICE is defined.
> of.h needs to be included directly.
>
> Signed-off-by: Guenter Roeck
Thanks, Guenter! (of course it's way too late for Acked-by: Pawel Moll
)
Pawel
--
To unsubscribe from this
On Sun, 2013-01-06 at 09:16 +, Guenter Roeck wrote:
> Compiling vexpress client drivers as module results in error messages such as
>
> ERROR: "__vexpress_config_func_get" [drivers/hwmon/vexpress.ko] undefined!
> ERROR: "vexpress_config_func_put" [drivers/hwmon/vexpress.ko] undefined!
>
> Thi
1 - 100 of 374 matches
Mail list logo
