[PATCH v9] mfd: Add anatop mfd driver
From: Ying-Chun Liu (PaulLiu) paul@linaro.org
Anatop is a mfd chip embedded in Freescale i.MX6Q SoC.
Anatop provides regulators and thermal.
This driver handles the address space and the operation of the mfd device.
Signed-off-by: Ying-Chun Liu (PaulLiu) paul@linaro.org
Acked-by: Shawn Guo shawn@linaro.org
Cc: Samuel Ortiz sa...@linux.intel.com
Cc: Mark Brown broo...@opensource.wolfsonmicro.com
Cc: Venu Byravarasu vbyravar...@nvidia.com
Cc: Peter Korsgaard jac...@sunsite.dk
---
drivers/mfd/Kconfig|8 +++
drivers/mfd/Makefile |1 +
drivers/mfd/anatop-mfd.c | 142
include/linux/mfd/anatop.h | 40
4 files changed, 191 insertions(+), 0 deletions(-)
create mode 100644 drivers/mfd/anatop-mfd.c
create mode 100644 include/linux/mfd/anatop.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 82da448..c3a9f31 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -846,6 +846,14 @@ config MFD_INTEL_MSIC
Passage) chip. This chip embeds audio, battery, GPIO, etc.
devices used in Intel Medfield platforms.
+config MFD_ANATOP
+ bool Support for Freescale i.MX on-chip ANATOP controller
+ depends on SOC_IMX6Q
+ help
+ Select this option to enable Freescale i.MX on-chip ANATOP
+ MFD controller. This controller embeds regulator and
+ thermal devices for Freescale i.MX platforms.
+
endmenu
endif
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 27430d3..42c8bf6 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -113,3 +113,4 @@ obj-$(CONFIG_TPS65911_COMPARATOR) += tps65911-comparator.o
obj-$(CONFIG_MFD_AAT2870_CORE) += aat2870-core.o
obj-$(CONFIG_MFD_INTEL_MSIC) += intel_msic.o
obj-$(CONFIG_MFD_S5M_CORE) += s5m-core.o s5m-irq.o
+obj-$(CONFIG_MFD_ANATOP) += anatop-mfd.o
diff --git a/drivers/mfd/anatop-mfd.c b/drivers/mfd/anatop-mfd.c
new file mode 100644
index 000..4272e60
--- /dev/null
+++ b/drivers/mfd/anatop-mfd.c
@@ -0,0 +1,142 @@
+/*
+ * Anatop MFD driver
+ *
+ * Copyright (C) 2012 Ying-Chun Liu (PaulLiu) paul@linaro.org
+ * Copyright (C) 2012 Linaro
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License along
+ * with this program; if not, write to the Free Software Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ */
+
+#include linux/io.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/of.h
+#include linux/of_platform.h
+#include linux/of_address.h
+#include linux/mfd/anatop.h
+
+u32 anatop_get_bits(struct anatop *adata, u32 addr, int bit_shift,
+ int bit_width)
+{
+ u32 val, mask;
+
+ if (bit_width == 32)
+ mask = ~0;
+ else
+ mask = (1 bit_width) - 1;
+
+ val = readl(adata-ioreg + addr);
+ val = (val bit_shift) mask;
+
+ return val;
+}
+EXPORT_SYMBOL(anatop_get_bits);
+
+void anatop_set_bits(struct anatop *adata, u32 addr, int bit_shift,
+int bit_width, u32 data)
+{
+ u32 val, mask;
+
+ if (bit_width == 32)
+ mask = ~0;
+ else
+ mask = (1 bit_width) - 1;
+
+ spin_lock(adata-reglock);
+ val = readl(adata-ioreg + addr) ~(mask bit_shift);
+ writel((data bit_shift) | val, adata-ioreg + addr);
+ spin_unlock(adata-reglock);
+}
+EXPORT_SYMBOL(anatop_set_bits);
+
+static const struct of_device_id of_anatop_subdevice_match[] = {
+ { .compatible = fsl,anatop-regulator, },
+ { .compatible = fsl,anatop-thermal, },
+ { },
+};
+
+static int __devinit of_anatop_probe(struct
Re: [PATCH v9] mfd: Add anatop mfd driver
On Thursday 15 March 2012, Ying-Chun Liu (PaulLiu) wrote:
From: Ying-Chun Liu (PaulLiu) paul@linaro.org
Anatop is a mfd chip embedded in Freescale i.MX6Q SoC.
Anatop provides regulators and thermal.
This driver handles the address space and the operation of the mfd device.
Hi Paul,
This looks like a very nice and clean driver, good work!
Very broadly speaking, I wonder whether we could use the regmap
infrastructure for these things in the future, but I would first
need to understand whether that is actually in the scope of regmap.
It seems that you just need a subset of what regmap provides,
so it could work, but it might not actually be better than what
you have now.
Mark, can you comment on that?
+u32 anatop_get_bits(struct anatop *adata, u32 addr, int bit_shift,
+ int bit_width)
+{
+ u32 val, mask;
+
+ if (bit_width == 32)
+ mask = ~0;
+ else
+ mask = (1 bit_width) - 1;
+
+ val = readl(adata-ioreg + addr);
+ val = (val bit_shift) mask;
+
+ return val;
+}
+EXPORT_SYMBOL(anatop_get_bits);
I think the exports here should be EXPORT_SYMBOL_GPL. There is no reason
why an out of tree driver would ever use these.
+static const struct of_device_id of_anatop_subdevice_match[] = {
+ { .compatible = fsl,anatop-regulator, },
+ { .compatible = fsl,anatop-thermal, },
+ { },
+};
+
+static int __devinit of_anatop_probe(struct platform_device *pdev)
+{
+ struct device *dev = pdev-dev;
+ struct device_node *np = dev-of_node;
+ void *ioreg;
+ struct anatop *drvdata;
+
+ ioreg = of_iomap(np, 0);
+ if (!ioreg)
+ return -EADDRNOTAVAIL;
+ drvdata = devm_kzalloc(dev, sizeof(*drvdata), GFP_KERNEL);
+ if (!drvdata)
+ return -ENOMEM;
+ drvdata-ioreg = ioreg;
+ spin_lock_init(drvdata-reglock);
+ platform_set_drvdata(pdev, drvdata);
+ of_platform_bus_probe(np, of_anatop_subdevice_match, dev);
+
+ return 0;
+}
Why do you list the subdevices in of_anatop_subdevice_match()? I think you
should just use
of_platform_bus_probe(np, of_anatop_match, dev);
here, using the same match table that you have in the platform_driver.
That will automatically create platform devices for any children of this
device, so you don't have to update the list above when you get new
child drivers.
Arnd
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v6 2/3] clk: introduce the common clock framework
On Wed, Mar 14, 2012 at 05:51:48PM -0700, Turquette, Mike wrote:
On Tue, Mar 13, 2012 at 5:05 AM, Sascha Hauer s.ha...@pengutronix.de wrote:
On Mon, Mar 12, 2012 at 08:16:36PM -0700, Turquette, Mike wrote:
On Mon, Mar 12, 2012 at 4:51 AM, Sascha Hauer s.ha...@pengutronix.de
wrote:
I tried another
approach on the weekend which basically does not try to do all in a
single recursion but instead sets the rate in multiple steps:
1) call a function which calculates all new rates of affected clocks
in a rate change and safes the value in a clk-new_rate field. This
function returns the topmost clock which has to be changed.
2) starting from the topmost clock notify all clients. This walks the
whole subtree even if a notfifier refuses the change. If necessary
we can walk the whole subtree again to abort the change.
3) actually change rates starting from the topmost clocks and notify
all clients on the way. I changed the set_rate callback to void.
Instead of failing (what is failing in case of set_rate? The clock
will still have some rate) I check for the result with
clk_ops-recalc_rate.
The way described above works for me now, see this branch:
git://git.pengutronix.de/git/imx/linux-2.6.git v3.3-rc6-clkv6-fixup
You may not necessarily like it as it changes quite a lot in the rate
changing code.
I tried that code and I really like it! It is much more readable and
feels less fragile than the previous recursive __clk_set_rate. I
did quite a bit of testing with this code today. One of the tests
looks like this:
pll (adjustable to anything)
|
clk_divider (5 bits wide)
|
dummy(no clk_ops)
The new code did a fine job arbitrating rates for the PLL and the
intermediate divider even if I put weird constraints on the PLL. For
instance if I artificially limited it to a minimum of 600MHz and then
ran clk_set_rate(dummy, 300MHz) it would lock at 600MHz and set
clk_divider to divide-by-2. Setting to 600MHz or more set the divider
back to 1 and relocked the PLL appropriately. Pretty cool.
I also tested the notifiers with this code and they seem to function
properly. I'll take this code in for v7. Thanks a lot for this
helpful contribution.
I did find that MULT_ROUND_UP caused trouble for my PLL's round_rate
implementation. Maybe my PLL code is fragile but a quick fix was to
make sure that we send the exact value we want to the round_rate code.
I also feel this is more correct. Let me know what you think:
8---
commit 189fecedb175d0366759246c4192f45b0bc39a50
Author: Mike Turquette mturque...@linaro.org
Date: Wed Mar 14 17:29:51 2012 -0700
clk-divider.c: round the actual rate we care about
diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
index 86ca9cd..06ef4a0 100644
--- a/drivers/clk/clk-divider.c
+++ b/drivers/clk/clk-divider.c
@@ -47,12 +47,6 @@ static unsigned long clk_divider_recalc_rate(struct
clk_hw *hw,
}
EXPORT_SYMBOL_GPL(clk_divider_recalc_rate);
-/*
- * The reverse of DIV_ROUND_UP: The maximum number which
- * divided by m is r
- */
-#define MULT_ROUND_UP(r, m) ((r) * (m) + (m) - 1)
-
static int clk_divider_bestdiv(struct clk_hw *hw, unsigned long rate,
unsigned long *best_parent_rate)
{
@@ -84,9 +78,9 @@ static int clk_divider_bestdiv(struct clk_hw *hw,
unsigned long rate,
for (i = 1; i = maxdiv; i++) {
parent_rate = __clk_round_rate(__clk_get_parent(hw-clk),
- MULT_ROUND_UP(rate, i));
+ (rate * i));
I think MULT_ROUND_UP is the right thing to use here (not sure if this
is a good name though)
Consider we want to have an output rate of 33Hz. Now acceptable input
rates for a divider value of 3 would be 99, 100 and 101Hz, so we have
to call round_rate for the parent with 101Hz which includes 100 and
99Hz.
If you have problems with your PLL than most likely because it does
something different on clk_round_rate than it does in clk_set_rate,
for example clk_round_rate(1) returns 1, but clk_set_rate then
sets the rate due to some rounding error. Being consistent between
round_rate and set_rate is very important for this mechanism to work
properly. It did cost me some nerves to get it right for the divider
(and even more nerves to figure out why it is correct the way it works)
now = parent_rate / i;
- if (now = rate now = best) {
+ if (now = rate now best) {
This change is an optimization, but should be unrelated to your PLL
problem, right?
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht
Re: Slow/broken USB and Ethernet on Snowballs/Origen boards?
Hey, On 03/15/2012 01:39 AM, Tony Mansson wrote: Hi, This is interesting. I'd like to reproduce the Ethernet speed tests. Do you have the exact command lines? Sure. You'll need two machines, on being the board. Both need to be in the same 100 or 1000 MBit/s LAN. On the receiver's end, run: netcat -l 8000 /dev/null This will listen for incoming data on a TCP socket on port 8000. Then, given the receiver's IP address, run the following command on the sender's end: dd if=/dev/zero bs=1024k count=256 /dev/tcp/RECEIVER IP/8000 Note that /dev/tcp/XYZ/8000 is a bash-specific feature. When this command has finished, it will tell you the transfer rate. You can cancel it anytime and it will give you the same information. But be sure not to cancel too early as that makes the measurement less reliable. Obviously, you can change count= to whatever you want. E.g. with the Origen, you'd probably want to only send 10-100 MByte. Also, you can swap receiver and sender to make sure that running netcat on the board is not causing things to slow down. Not the best benchmark in the world, but it's simple and you can run it as often if you want to make it more reliable. Hope that helps, Jannis -- Forwarded message -- From: Jannis Pohlmann jannis.pohlm...@codethink.co.uk Date: 14 March 2012 21:04 Subject: Slow/broken USB and Ethernet on Snowballs/Origen boards? To: linaro-dev@lists.linaro.org Hi, I am currently playing with a couple of the development boards for which there are Linaro hwpacks and LEBs. Since what I am trying to do requires a lot of disk and network I/O, I've been paying special attention to the data transfer rates I can get out of these boards. Below is a brief summary of my findings. 1) i.MX 53 * disk I/O using an external SSD drive is very good; good enough to not require further measurements * network I/O is approximately 9-10 MByte/s (perhaps more) which seems ok given the 100 MBit/s Ethernet interface 2) Snowball (PDK, version 8) * it seems to be impossible to get the USB OTG host mode to work, therefore I could not test disk I/O with a USB drive; it appears the OTG port on the version 8 board does not even have enough power for a powered USB to actually go online (I am unaware of the details of how this works unfortunately) * performing network I/O with netcat casues netcat, ksoftirqd and kworker to use ~33% of the CPU each, resulting in 100% CPU usage only to handle the network data transfer * the resulting network transfer rate is about 5.5 MByte/s, which is significantly less than what the 100 MBit/s Ethernet interface should be able to produce 3) Origen * the internal USB hub runs at Full Speed (12 MBit/s), resulting in a maximum USB disk I/O of 1.5 MByte/s * since the board does not feature Ethernet itself, I tried to attach a USB Ethernet controller to it, but of course the transfer rate through that is by the I/O upper limit of the USB hub * I did not test wireless but it is not feasible for what I am trying to do anyway I guess not all of this is surprising. The i.MX performs quite well but unfortunately the CPU is quite slow compared to the others. However, I wonder whether the USB OTG host mode issue on the Snowball is a known problem? Also, network I/O occupying all of the CPU seems to be a bug or at least a dodgy driver. About the Origen: I assume there is nothing that can be done to have High Speed USB on it? Thanks in advance! If anyone needs me to provide more information, I'll gladly try to do that. Regards, Jannis ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Slow/broken USB and Ethernet on Snowballs/Origen boards?
On 15 March 2012 15:39, Jannis Pohlmann jannis.pohlm...@codethink.co.uk wrote: Hey, On 03/15/2012 01:39 AM, Tony Mansson wrote: Hi, This is interesting. I'd like to reproduce the Ethernet speed tests. Do you have the exact command lines? Sure. You'll need two machines, on being the board. Both need to be in the same 100 or 1000 MBit/s LAN. On the receiver's end, run: netcat -l 8000 /dev/null This will listen for incoming data on a TCP socket on port 8000. Then, given the receiver's IP address, run the following command on the sender's end: dd if=/dev/zero bs=1024k count=256 /dev/tcp/RECEIVER IP/8000 Cool. You might also want to take a look at 'netperf', a small yet powerful tool. At least until 2006(when I last used it) it was a piece of cake to use. cheers -jassi ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Slow/broken USB and Ethernet on Snowballs/Origen boards?
W dniu 15.03.2012 11:31, Jassi Brar pisze: Cool. You might also want to take a look at 'netperf', a small yet powerful tool. Or iperf which I use for bandwidth tests. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v9] mfd: Add anatop mfd driver
On Thu, Mar 15, 2012 at 09:07:29AM +, Arnd Bergmann wrote: Very broadly speaking, I wonder whether we could use the regmap infrastructure for these things in the future, but I would first need to understand whether that is actually in the scope of regmap. It seems that you just need a subset of what regmap provides, so it could work, but it might not actually be better than what you have now. Mark, can you comment on that? There were some other mutterings about using regmap for memory mapped devices, mostly from the point of view of building framework features like this on top of it. regmap currently makes some assumptions that the I/O is going to be slow so approximately any amount of CPU time can usefully be spent on avoiding I/O but we can probably do something about that. It also uses mutexes to lock I/O which might not be the most sensible thing for memory mapped devices, but again that's solveable. Right now there's no memory mapping support but there's no reason that can't be added. In short, it does seem sensible to want to have some support for this for devices that use appropriate idioms. signature.asc Description: Digital signature ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Question] How To Log QEMU Memory Access
Dear Peter Maydell, Thanks for your reply. Would you mind give me more help? My PC architecture is x86, so the tcg_out_qemu_ld() and tcg_out_qemu_st() is in tcg/i386/tcg-target.c. Nevertheless, it is difficult for me to understand them completely. Do you means that the QEMU TLB maps the guest virtual address to host virtual address, and the begging and end virtual addresses of the memory allocated for RAM device emulating are the RAM physical begging and end address from guest view? If so, it seems hard to monitor the guest physical memory. However, [exec.c:qemu_get_ram_ptr] seems to get a host virtual address from a guest physical address. It confuses me. Would you mind explain more details about QEMU TLB? Any comments will be appreciated. Thanks much! Thanks, Jerry 2012/3/14 Peter Maydell peter.mayd...@linaro.org On 14 March 2012 14:01, 周春华 uuli...@gmail.com wrote: I got a job that should log the RAM memory access in the QEMU. First, I should find out the code line in QEMU to trap all RAM memory access. After some efforts, I have some conclusions: 1. I have found the function dealing with the translation from the virtual address to physical address in the guest of QEMU, such as [target-arm/helper.c:get_phys_addr], and the page fault handler function [target-arm/helper.c:cpu_arm_handle_mmu_fault]. However, we have not found out the routine of accessing physical address from MMU TLB entry. The TLB lookup and reading of the host RAM is done by generated code (for instance on an x86 host this code is generated by tcg_out_qemu_ld() and tcg_out_qemu_st() in tcg/i386/tcg-target.c). NB that the QEMU TLB goes straight from guest virtual address to host address when it's reading RAM, without passing through a guest physical address. I'm afraid there's no convenient place to put logging of memory accesses in this code, because it is designed for speed rather than ease of instrumentation. -- PMM ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Question] How To Log QEMU Memory Access
2012/3/15 周春华 uuli...@gmail.com: Do you means that the QEMU TLB maps the guest virtual address to host virtual address, Yes. and the begging and end virtual addresses of the memory allocated for RAM device emulating are the RAM physical begging and end address from guest view? I don't know what you mean by this. RAM in qemu need not be contiguous in guest physical address space, and it need not be contiguous in host physical address space either. If so, it seems hard to monitor the guest physical memory. Yes, that's what I said. However, [exec.c:qemu_get_ram_ptr] seems to get a host virtual address from a guest physical address. It confuses me. Obviously QEMU knows how to map between guest physical addresses and host virtual addresses, or it wouldn't work. This function is one very small part of a complicated subsystem which caches the guest virtual - guest physical - host virtual lookups so we don't need to do them again and again when we execute load or store instructions. If you want to follow the code in more detail, when QEMU gets a TLB miss (ie it doesn't know where the RAM for a guest virtual address is) it calls target-arm/helper.c:cpu_arm_handle_mmu_fault(). This calls get_phys_addr() to do a page table walk and convert the guest virtual address to a guest physical address. Assuming that succeeded, it calls exec.c:tlb_set_page(), passing the guest virtual and guest physical addresses, to add a TLB entry. This function calls memory_region_get_ram_ptr() which in turn calls qemu_get_ram_ptr(), getting the host virtual address. We can then cache the host virtual address for this guest virtual address in the TLB entry. Later on when we actually execute a guest load or store instruction we will pull the TLB entry out of the data structure and use the host virtual address cached in it. tcg_out_qemu_ld/st are the functions which generate the native code which gets the TLB entry and loads via the cached host virtual address. Note that there are other slow paths for memory access which don't use the TLB and instead do go via physical addresses at the time they need to do the load/store. -- PMM ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Announce: live-build a45
On 03/14/2012 09:15 PM, Tom Gall wrote: Located in ppa:linaro-maintainers/tools can be found the newest version of live-build, a45 with the following linaro features applied: 1) armhf support (both native and cross) 2) linaro meta bld information as was discussed at 4Q11 Linaro Connect 3) cross support using multistrap Hi Tom, what are the chances of these changes getting into the live-build carried in Ubuntu 12.04? thanks Jani ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Question] How To Log QEMU Memory Access
Dear Peter Maydell, I am very appreciated for you great help. There is still a question exist: Note that there are other slow paths for memory access which don't use the TLB and instead do go via physical addresses at the time they need to do the load/store. I want to know how to use these slow paths. Will they will guest virtual - guest physical - host virtual again and again when we execute load or store instructions. If so, I prefer to use them instead. It will help me to log the memory access. Any way, I want to thank you again. Best Regards, Jerry 2012/3/15 Peter Maydell peter.mayd...@linaro.org 2012/3/15 周春华 uuli...@gmail.com: Do you means that the QEMU TLB maps the guest virtual address to host virtual address, Yes. and the begging and end virtual addresses of the memory allocated for RAM device emulating are the RAM physical begging and end address from guest view? I don't know what you mean by this. RAM in qemu need not be contiguous in guest physical address space, and it need not be contiguous in host physical address space either. If so, it seems hard to monitor the guest physical memory. Yes, that's what I said. However, [exec.c:qemu_get_ram_ptr] seems to get a host virtual address from a guest physical address. It confuses me. Obviously QEMU knows how to map between guest physical addresses and host virtual addresses, or it wouldn't work. This function is one very small part of a complicated subsystem which caches the guest virtual - guest physical - host virtual lookups so we don't need to do them again and again when we execute load or store instructions. If you want to follow the code in more detail, when QEMU gets a TLB miss (ie it doesn't know where the RAM for a guest virtual address is) it calls target-arm/helper.c:cpu_arm_handle_mmu_fault(). This calls get_phys_addr() to do a page table walk and convert the guest virtual address to a guest physical address. Assuming that succeeded, it calls exec.c:tlb_set_page(), passing the guest virtual and guest physical addresses, to add a TLB entry. This function calls memory_region_get_ram_ptr() which in turn calls qemu_get_ram_ptr(), getting the host virtual address. We can then cache the host virtual address for this guest virtual address in the TLB entry. Later on when we actually execute a guest load or store instruction we will pull the TLB entry out of the data structure and use the host virtual address cached in it. tcg_out_qemu_ld/st are the functions which generate the native code which gets the TLB entry and loads via the cached host virtual address. Note that there are other slow paths for memory access which don't use the TLB and instead do go via physical addresses at the time they need to do the load/store. -- PMM -- I love linux!!! ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Slow/broken USB and Ethernet on Snowballs/Origen boards?
On 14 March 2012 20:04, Jannis Pohlmann jannis.pohlm...@codethink.co.uk wrote: Hi, I am currently playing with a couple of the development boards for which there are Linaro hwpacks and LEBs. Since what I am trying to do requires a lot of disk and network I/O, I've been paying special attention to the data transfer rates I can get out of these boards. Below is a brief summary of my findings. 3) Origen * the internal USB hub runs at Full Speed (12 MBit/s), resulting in a maximum USB disk I/O of 1.5 MByte/s * since the board does not feature Ethernet itself, I tried to attach a USB Ethernet controller to it, but of course the transfer rate through that is by the I/O upper limit of the USB hub * I did not test wireless but it is not feasible for what I am trying to do anyway Which kernel version are you using on the Origen? I noticed the same problem a while back, but it appears to have been fixed in the Samsung landing team tree. There is still another bug present in the Origen kernel preventing USB-ethernet working with EHCI. Some patches have been posted, but they have not made it into the trees yet. Search the mailing lists for s5p usb burst to find them. -- Mans Rullgard / mru ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Question] How To Log QEMU Memory Access
2012/3/15 周春华 uuli...@gmail.com: Peter Maydell wrote: Note that there are other slow paths for memory access which don't use the TLB and instead do go via physical addresses at the time they need to do the load/store. I want to know how to use these slow paths. Will they will guest virtual - guest physical - host virtual again and again when we execute load or store instructions. No, you don't get to choose whether slow or fast paths are used. QEMU uses the fast paths where it can, and occasionally also the slow paths in odd corner cases or less often used operations. -- PMM ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Announce: live-build a45
On 15 March 2012 15:20, Jani Monoses wrote: On 03/14/2012 09:15 PM, Tom Gall wrote: Located in ppa:linaro-maintainers/tools can be found the newest version of live-build, a45 with the following linaro features applied: 1) armhf support (both native and cross) 2) linaro meta bld information as was discussed at 4Q11 Linaro Connect 3) cross support using multistrap Hi Tom, what are the chances of these changes getting into the live-build carried in Ubuntu 12.04? 1) armhf support (both native and cross) is supported by upstream version 2) linaro meta support is missing upstream 3) cross support using debootstrap is supported upstream That said, it make more sense to merge upstream live-build 3.0 a45. Btw, that's the version I'm using to build Precise armhf preview images: https://ci.linaro.org/jenkins/view/Ubuntu%20Build%20Service/ Cheers, Fathi ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Question] How To Log QEMU Memory Access
Dear Peter Maydell, Thank you for your help. I got an idea to log the guest physical address, would you mind help me to check it? Because the function tcg_out_qemu_ld() and tcg_out_qemu_st() know the guest virtual address should be accessed, we can call the [target-arm/helper.c:get_phys_addr] function to translate the guest virtual address to the guest physical address and log the guest physical address. Is it feasible? I know it will be slow the QEMU. Best Regards, Jerry 2012/3/15 Peter Maydell peter.mayd...@linaro.org 2012/3/15 周春华 uuli...@gmail.com: Peter Maydell wrote: Note that there are other slow paths for memory access which don't use the TLB and instead do go via physical addresses at the time they need to do the load/store. I want to know how to use these slow paths. Will they will guest virtual - guest physical - host virtual again and again when we execute load or store instructions. No, you don't get to choose whether slow or fast paths are used. QEMU uses the fast paths where it can, and occasionally also the slow paths in odd corner cases or less often used operations. -- PMM -- I love linux!!! ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Slow/broken USB and Ethernet on Snowballs/Origen boards?
Hey, On 03/15/2012 01:26 PM, Mans Rullgard wrote: On 14 March 2012 20:04, Jannis Pohlmann jannis.pohlm...@codethink.co.uk wrote: 3) Origen * the internal USB hub runs at Full Speed (12 MBit/s), resulting in a maximum USB disk I/O of 1.5 MByte/s * since the board does not feature Ethernet itself, I tried to attach a USB Ethernet controller to it, but of course the transfer rate through that is by the I/O upper limit of the USB hub * I did not test wireless but it is not feasible for what I am trying to do anyway Which kernel version are you using on the Origen? I noticed the same problem a while back, but it appears to have been fixed in the Samsung landing team tree. Here's the output of 'uname -a': Linux linaro-developer 3.2.0-1000-origen #0samsung14-Ubuntu SMP PREEMPT Wed Jan 11 18:56:28 UTC 2012 armv7l armv7l armv7l GNU/Linux Got the kernel from http://snapshots.linaro.org/oneiric/lt-origen-oneiric/20120313/1/ There is still another bug present in the Origen kernel preventing USB-ethernet working with EHCI. Some patches have been posted, but they have not made it into the trees yet. Search the mailing lists for s5p usb burst to find them. Is there any estimate on when this (them being merged into the landing team trees) might happen? - Jannis ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH v9] mfd: Add anatop mfd driver
On Thursday 15 March 2012, Mark Brown wrote: There were some other mutterings about using regmap for memory mapped devices, mostly from the point of view of building framework features like this on top of it. regmap currently makes some assumptions that the I/O is going to be slow so approximately any amount of CPU time can usefully be spent on avoiding I/O but we can probably do something about that. It also uses mutexes to lock I/O which might not be the most sensible thing for memory mapped devices, but again that's solveable. Right now there's no memory mapping support but there's no reason that can't be added. In short, it does seem sensible to want to have some support for this for devices that use appropriate idioms. Ok, I see. I guess there is no reason to change anything in Paul's patch now, but we can keep this in mind if we see a lot of similar drivers in the future. Thanks, Arnd ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
RE: Do ARM Cortex-A9 PMU supoort oprofile
As far as I know this has not happened. Such a change would also have to include making the use of timer interrupts (as opposed to PMU counter interrupts) selectable at runtime. I believe the use of timer interrupts for oprofile data collection is still a configuration/boot option. Alternatively we could just decide to deconfigure PMU hardware counters by default to make timers accessible. -dl Missed that mail while in vacation. OK, you confirm it did not happen. I read usage of PMU mostly to wake-up every X cycles so timer by default + tunable timer would be OK until we go to r3p0 revisions where PMU bug is solved. Or, if people are OK to lose some interrupts, please speak out, that would be Ok if losses are not too bursty ;-) However, having the capability to read PMU counters everytime timer triggers would be important to track things like cache misses. I have seen this is adressed in parallel thread. Regards Fred Texas Instruments France SA, 821 Avenue Jack Kilby, 06270 Villeneuve Loubet. 036 420 040 R.C.S Antibes. Capital de EUR 753.920 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Changes to Blueprint work items in Launchpad
Hi there, Launchpad now supports blueprint work items natively and we've already migrated the work items from the whiteboards of most Linaro Blueprints. Most of us wouldn't even notice those changes because we still have a text field to enter work items and it uses the exact same format we used before. In the future we might improve the user experience but for now we decided to keep the same UI and format. There's a blog post with more information, if you're curious: http://blog.launchpad.net/ In practice this just means you'll enter the work items in the 'Work items' field instead of the whiteboard (the meta info [acceptance/headline] still go there, though), but the work items of some of our Blueprints could not be migrated, so I've spammed^W sent an email to the owner/assignee of each of them. It would be nice if those of you who receive that email migrated your BPs manually but even if you don't status.l.o is setup to pull work items from both the new field and the whiteboard, so you'll still see your work items there. And if you're curious why we're doing all this, it's so that we can implement the monthly engineering views in Launchpad: https://dev.launchpad.net/Projects/WorkItems Cheers, -- Guilherme Salgado https://launchpad.net/~salgado signature.asc Description: OpenPGP digital signature ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Announcing Linarotv-xmbc image
On Mon, Mar 12, 2012 at 7:08 AM, Avik Sil avik@linaro.org wrote: On 12 March 2012 11:28, Belisko Marek marek.beli...@gmail.com wrote: Hi, On Thu, Jan 26, 2012 at 12:30 AM, Tom Gall tom.g...@linaro.org wrote: For the 12.01 cycle the Linaro Platforms team is pleased to announce the availability of the new linarotv-xbmc based image. This combines the xbmc media server project with linaro's leb to result in a works out of the box arm based media server image. It can be found at http://snapshots.linaro.org/oneiric/linaro-o-linarotv-xbmc/ Just tyring to unpack linaro-xbmc with linaro-media-create tool on 2GB SD card but when creating rootfs I get error no space left on device. Do I need bigger SD card or I'm doing something wrong? Yes, you need a bigger SD card. I'm using now 8G SD card but appear another problem. During linaro-media-create I got: Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libc6-dev : Depends: libc6 (= 2.13-20ubuntu5) but 2.13-20ubuntu5.1 is to be installed E: Broken packages Cleaning up ...Done proc has been unmounted Traceback (most recent call last): File /usr/bin/linaro-media-create, line 163, in module verified_files, *hwpacks) File /usr/lib/pymodules/python2.7/linaro_image_tools/media_create/chroot_utils.py, line 79, in install_hwpacks install_hwpack(chroot_dir, hwpack_file, hwpack_force_yes or hwpack_verified) File /usr/lib/pymodules/python2.7/linaro_image_tools/media_create/chroot_utils.py, line 100, in install_hwpack cmd_runner.run(args, as_root=True, chroot=chroot_dir).wait() File /usr/lib/pymodules/python2.7/linaro_image_tools/cmd_runner.py, line 100, in wait raise SubcommandNonZeroReturnValue(self._my_args, returncode) linaro_image_tools.cmd_runner.SubcommandNonZeroReturnValue: Sub process ['chroot', '/tmp/tmpPFtRei/binary', 'linaro-hwpack-install', '/hwpack_linaro-lt-panda-x11-base_20120221-1_armel_supported.tar.gz'] returned a non-zero value: 100 I'm using Ubuntu 11.10. Seems some dependencies are met but be honest I'm lost ;) Thanks for any help. Currently the best experience can be found on Panda/Panda ES however boards with hardware video acceleration enabled should work well. We welcome feedback and suggestions on the image. Support is on a as best can basis. Bugs if found should be written against linaro-ubuntu in lauchpad. Enjoy! -- Regards, Tom Where's the kaboom!? There was supposed to be an earth-shattering kaboom! Marvin Martian Multimedia Tech Lead | Linaro.org │ Open source software for ARM SoCs w) tom.gall att linaro.org w) tom_gall att vnet.ibm.com h) tom_gall att mac.com ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev regards, marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev Regards, Avik marek -- as simple and primitive as possible - Marek Belisko - OPEN-NANDRA Freelance Developer Ruska Nova Ves 219 | Presov, 08005 Slovak Republic Tel: +421 915 052 184 skype: marekwhite twitter: #opennandra web: http://open-nandra.com ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 05/07] Watchdog: DA9052/53 watchdog support v1
Hi Ashish, Any update on below patch? On Mon, 2012-02-06 at 18:18 +0530, Ashish Jangam wrote: This driver adds support for the watchdog functionality provided by the Dialog Semiconductor DA9052/53 PMIC chip. This patch is functionally tested on Samsung SMDKV6410. Signed-off-by: David Dajun Chen dc...@diasemi.com Signed-off-by: Ashish Jangam ashish.jan...@kpitcummins.com --- Documentation/watchdog/watchdog-parameters.txt |5 + drivers/watchdog/Kconfig |6 + drivers/watchdog/Makefile |1 + drivers/watchdog/da9052_wdt.c | 333 4 files changed, 345 insertions(+), 0 deletions(-) What's the difference with the version of Fri, 5 Aug 2011 19:21:51 +0530 ? Kind regards, Wim. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Plan for changing the binary toolchain to 4.7 and hardfloat
Hi there. Over the next three months both GCC 4.7 and Ubuntu 12.04 'Precise' are coming out. We'll switch over to these pretty quickly which will affect our internal testing and anyone using the binary toolchain. The changeover plan including dates, details of what's happening, and backwards compatibility is at: https://wiki.linaro.org/MichaelHope/Sandbox/BinariesMigration Comments and concerns are welcome, -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
LAVA Downtime Planned
This is just an early notification that the Linaro validation farm will be physically moving to a new site next week. Unfortunately, the network cables won't stretch that far, so it will mean some downtime. :) Here's the tentative plan: Wednesday, March 21st - the rack with the toolchain server will be shut down, crated and sent off Thursday, March 22nd - pretty much everything else will go offline (main LAVA server, development boards) Friday, March 23rd - physical move will happen, and if all goes well (what could possibly go wrong?!) the main site and as many of the boards as possible will go back online in their new home Saturday, March 24th to Sunday, March 25th - finish configuring and bringing up cloud services, toolchain server, etc. There's another bit of good news here, that the lab will be getting a much needed upgrade in the internet connection. A partial (but significant one) at first, and a bigger one in about a month or so with redundant connections. Bear in mind that this is just the tentative plan, Dave or I will send out a reminder and update as the date gets closer, or if something changes. Thanks, Paul Larson ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: LAVA Downtime Planned
On 16 March 2012 15:50, Paul Larson paul.lar...@linaro.org wrote: This is just an early notification that the Linaro validation farm will be physically moving to a new site next week. Unfortunately, the network cables won't stretch that far, so it will mean some downtime. :) Here's the tentative plan: Wednesday, March 21st - the rack with the toolchain server will be shut down, crated and sent off Thursday, March 22nd - pretty much everything else will go offline (main LAVA server, development boards) I'll pause the tcpanda boards on Tuesday and shut them down on Wednesday. Our release is done so this should be fine. -- Michael ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Slow/broken USB and Ethernet on Snowballs/Origen boards?
Hi, On 15/03/2012, Mans Rullgard mans.rullg...@linaro.org wrote: On 14 March 2012 20:04, Jannis Pohlmann jannis.pohlm...@codethink.co.uk wrote: Hi, I am currently playing with a couple of the development boards for which there are Linaro hwpacks and LEBs. Since what I am trying to do requires a lot of disk and network I/O, I've been paying special attention to the data transfer rates I can get out of these boards. Below is a brief summary of my findings. 3) Origen * the internal USB hub runs at Full Speed (12 MBit/s), resulting in a maximum USB disk I/O of 1.5 MByte/s * since the board does not feature Ethernet itself, I tried to attach a USB Ethernet controller to it, but of course the transfer rate through that is by the I/O upper limit of the USB hub * I did not test wireless but it is not feasible for what I am trying to do anyway Which kernel version are you using on the Origen? I noticed the same problem a while back, but it appears to have been fixed in the Samsung landing team tree. There is still another bug present in the Origen kernel preventing USB-ethernet working with EHCI. Some patches have been posted, but they have not made it into the trees yet. These patches have been added to Samsung LT tree [1]. [1] git://git.linaro.org/landing-teams/working/samsung/kernel.git (branch: tracking) Search the mailing lists for s5p usb burst to find them. -- Mans Rullgard / mru ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- With warm regards, Sachin ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
