Re: arndale ethernet not working on u-boot
On 8 November 2013 13:44, Daniel Lezcano daniel.lezc...@linaro.org wrote: Hi all, I have an arndale and I am trying to have the ethernet working in u-boot but without success. (Re)start USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 2 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found scanning usb for ethernet devices... 0 Ethernet Device(s) found I found different bugs in launchpad but without this solved. I tried different u-boot but without success. Did someone faced this issue and solved it ? Thanks -- Daniel We have observed the issue with upstream u-boot, but haven't got any solution to this problem yet. -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: arndale board power measurement
On 07/19/2013 08:39 PM, Rajiv Nishtala wrote: Hi, My name is Rajiv Nishtala and I am PhD student at UPC, Barcelona. I am trying to run some benchmarks on the arndale board and measure the power reading from it. is there a way to measure the power from the board directly, I tried using the wattsup .net meter and was not successful. At the moment, I am trying to use 32 system configuration registers, sys_cfs to measure the power, but the method seems to be very difficult for me. Would you suggest using any other technique? From the /sys/ folder, i found the following: /sys/devices/voltage-regulator.5/regulator/regulator.1 more uevent OF_NAME=voltage-regulator OF_FULLNAME=/voltage-regulator OF_COMPATIBLE_0=regulator-fixed OF_COMPATIBLE_N=1 But i am not sure what voltage it is referring to. Could you please shed some light here. Thanks. Rajiv Nishtala I haven't worked much on power measurement on Arndale, but there are others in Linaro who are actively using Arndale board for various power management activities. Ccing the linaro developers' mailing list where you can get some interesting information. -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [ANNOUNCE] linux-linaro kernel schedule / llct age
Timely updates on llct for each mainline -rc are very interesting though, in fact we depend on them. +1. -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Mali-ization
On 04/16/2013 09:46 AM, Andy Green wrote: On 16/04/13 10:08, the mail apparently from Selina Kuo included: Hi, John, Your assumption is right. The ump code is part of the out-of-tree mali driver. - Selina Kuo, one of Andy's colleagues ^^ As Selina says it's a code drop we got via Fujitsu from ARM for the OOT Mali driver. However that code is all GPL2, as it should be. I think any of the options are good, - make our own repo and keep it in sync with llct - privately encourage ARM to keep it in sync with Linus' HEAD, publicly - upstream it so it's always in sync This obviously helps of all LT who want to / can harmonize their tree on llct basis. Tushar, do you have any opinion? It would always help to have the Mali driver synced with latest upstream and getting merged into 'llct'. The LT's who need to use this driver can have their modifications (if any) on top of it. Anyone who dealt with this code or at ARM (Tixy?) FWIW our TSC rep is aware of this and I believe would support whatever the best-looking of these solutions is. -Andy On 16 April 2013 07:50, John Stultz john.stu...@linaro.org wrote: On 04/13/2013 03:22 AM, Andy Green wrote: On 13/04/13 09:07, the mail apparently from Andy Green included: I'm hoping someone else will write the patches ^^ but if not I'll try to sort something out. The attached series gets it building cleanly against current llct with ION. Cool. Although the patches look like they are all against the ump driver(which I'm not familiar with), as opposed to changes to the ION infrastructure itself. So they won't apply to the AOSP trees, and I can't send them upstream. I assume the ump code is part of the out-of-tree mali driver? Looking at llct, I don't see a drivers/base/ump directory. https://git.linaro.org/gitweb?p=kernel/linux-linaro-tracking.git;a=tree;f=drivers/base;h=cbad2d664fa248ec366430dbd1724b2959ae43ee;hb=refs/heads/linux-linaro-core-tracking But I'm guessing this is the point of your original mail in this thread: we need a mali tree upon which fixes like these can be applied and then pulled into llct. Or even better, can we get the mali devs to publish a repo of their latest work (to which fixes like Andy's can be submitted to) which can also be pulled into llct? thanks -john ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Samsung topic for 13.03
On 04/04/2013 12:40 PM, Alexander Spyridakis wrote: On 21 March 2013 06:33, Tushar Behera tushar.beh...@linaro.org wrote: I have been observing this system hang when we enable LPAE on 3.9 based llct, though the issue is not present with vanilla 3.9-rc kernel. Would update later after I debug further. Hello, I am not sure if this is still relevant but I get the same behaviour both on Arndale and Versatile Express with the latest linaro release. Check my suggested fix in linaro-kernelhttp://lists.linaro.org/pipermail/linaro-kernel/2013-April/003585.html . Regards. We have got an alternate fix here. This would be part of next release. It would be nice if you can test that at your end too. https://git.linaro.org/gitweb?p=landing-teams/working/samsung/kernel.git;a=commit;h=2265cef13cc7f3a131d68f3d175299dd23eac5c2 -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Looking for Linaro specific kernel
On 04/04/2013 09:31 PM, Jon Medhurst (Tixy) wrote: On Wed, 2013-04-03 at 16:08 +, Young, Chad wrote: I am looking for the kernel source 3.5.0-rc7 for the ARM versatile express system, does anyone know where I can find it? I've found another trick, if you can actually booting a Linaro kernel that you want the source for then early during boot you should see on the serial console something like: [0.00] Linux version 3.9.0-rc3-00212-g0f66281 ... You won't get the commit ID always. It basically prints the commit ID if current HEAD is not signed-tagged (or something like that). That is why, the hwpack kernels print like this. Linux version 3.9.0-1-linaro-arndale or if you have a console running on the device entering uname -a will give the same result. The part of the name after the '-g' part is the SHA1 of the git commit from which the kernel was built, e.g. in the above example it is 0f66281. You can then use this commit hash at the end of the URL for the gitweb interface of the to the git repo like this: https://git.linaro.org/gitweb?p=kernel/linux-linaro-tracking.git;a=commit;h=0f66281 and if the kernel was indeed built from that git repo then you should see the tip commit of the kernel source used to build the kernel. Now, I don't know how long our kernel names have included the SHA1 of the commit, so for old kernels this may not work. Also, some kernel releases didn't come out of the main Linaro kernel git. So this method isn't foolproof. -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Test Result Summary of Linaro 13.03 Release for Linux Linaro ubuntu Quantal.
On 03/28/2013 03:16 PM, Botao Sun wrote: Linaro 13.03 Release (Calendar Week 13): Here is test result summary for Linux Linaro ubuntu Quantal image on following boards: https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AgB-fT5LL31CdEtLTUtheGpkUU93V19EQnlYQjR4dXc#gid=2 [ ... ] 2. Samsung Arndale + Linux Linaro Quantal (Column I): https://docs.google.com/a/linaro.org/spreadsheet/ccc?key=0AgB-fT5LL31CdGZJSFdTUWFFYVdhZl8wMFpxLXd2TXc#gid=0 It keeps same status as last week: system hangs during the Power Management test, HDMI display is unavailable. All other features work well. I tested with the pre-built image [1]. HDMI is working at my setup. Can you please paste the bootlog? Alternately, assuming it was because of EDID failure, can you add following environment variable to bootargs and test? drm_kms_helper.edid_firmware=edid-1920x1080.fw [1] https://releases.linaro.org/13.03/ubuntu/arndale/arndale-quantal_server_20130324-276.img.gz -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Samsung topic for 13.03
Looks like the ll-20130320.0 kernel failed to boot on Arndale: http://validation.linaro.org/lava-server/scheduler/job/49985/log_file The build log is here: https://ci.linaro.org/jenkins/job/linux-linaro-tracking_arndale/62/consoleFull The kernel config has been made by the following command: 'ARCH=arm scripts/kconfig/merge_config.sh linaro/configs/linaro-base.conf linaro/configs/ubuntu-minimal.conf linaro/configs/arndale.conf linaro/configs/kvm-host.conf' Tushar, Have you tried this configuration? Thanks, Andrey I have been observing this system hang when we enable LPAE on 3.9 based llct, though the issue is not present with vanilla 3.9-rc kernel. Would update later after I debug further. Riku, How much essential is it to enable LPAE support for KVM? -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [ANNOUNCE] linux-linaro kernel schedule for 13.01
On 01/15/2013 02:59 PM, Andrey Konovalov wrote: Greetings, The current 13.01 schedule has been published on wiki: https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelSchedule Initial versions of llct and ll trees has been pushed to g.l.o, kernel/linux-linaro-tracking.git yesterday. The 13.01 release would be v3.8-rc4 based (tentative). Some changes vs 12.12: * new topic in ll for better Snowball support. Currently this is device tree, serial console, emmc, ethernet. * the perf-android patch(es) would be a separate ll topic. Thanks, Andrey ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev Samsung LT tree supporting Origen board on v3.8-rc3 has been pushed to glo. -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] clk: remove unreachable code
On 01/08/2013 06:33 PM, Rajagopal Venkat wrote: while reparenting a clock, NULL check is done for clock in consideration and its new parent. So re-check is not required. If done, else part becomes unreachable. Signed-off-by: Rajagopal Venkat rajagopal.ven...@linaro.org --- drivers/clk/clk.c |5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c index 251e45d..f896584 100644 --- a/drivers/clk/clk.c +++ b/drivers/clk/clk.c @@ -1048,10 +1048,7 @@ void __clk_reparent(struct clk *clk, struct clk *new_parent) hlist_del(clk-child_node); - if (new_parent) - hlist_add_head(clk-child_node, new_parent-children); - else - hlist_add_head(clk-child_node, clk_orphan_list); + hlist_add_head(clk-child_node, new_parent-children); #ifdef CONFIG_COMMON_CLK_DEBUG if (!inited) The same logic holds good for following piece of code too. 1060 |---if (new_parent) 1061 |---|---new_parent_d = new_parent-dentry; 1062 |---else 1063 |---|---new_parent_d = orphandir; -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] clk: remove unreachable code
On 01/09/2013 11:59 AM, Rajagopal Venkat wrote:
while reparenting a clock, NULL check is done for clock in
consideration and its new parent. So re-check is not required.
If done, else part becomes unreachable.
Signed-off-by: Rajagopal Venkat rajagopal.ven...@linaro.org
---
It is good to have revision history of the patches (version number and
changelog).
drivers/clk/clk.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 251e45d..1c4097c 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -1040,7 +1040,6 @@ void __clk_reparent(struct clk *clk, struct clk
*new_parent)
{
#ifdef CONFIG_COMMON_CLK_DEBUG
struct dentry *d;
- struct dentry *new_parent_d;
#endif
if (!clk || !new_parent)
@@ -1048,22 +1047,14 @@ void __clk_reparent(struct clk *clk, struct clk
*new_parent)
hlist_del(clk-child_node);
- if (new_parent)
- hlist_add_head(clk-child_node, new_parent-children);
- else
- hlist_add_head(clk-child_node, clk_orphan_list);
+ hlist_add_head(clk-child_node, new_parent-children);
#ifdef CONFIG_COMMON_CLK_DEBUG
if (!inited)
goto out;
- if (new_parent)
- new_parent_d = new_parent-dentry;
- else
- new_parent_d = orphandir;
-
d = debugfs_rename(clk-dentry-d_parent, clk-dentry,
- new_parent_d, clk-name);
+ new_parent-dentry, clk-name);
if (d)
clk-dentry = d;
else
--
Tushar Behera
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: When do we plan to move to Linux 3.8?
On 01/04/2013 08:03 PM, Andrey Konovalov wrote: On 01/04/2013 02:28 PM, Jon Medhurst (Tixy) wrote: On Fri, 2013-01-04 at 15:14 +0530, Viresh Kumar wrote: On 4 January 2013 15:09, Jon Medhurst (Tixy) t...@linaro.org wrote: I assume we'll be moving to Linux 3.8 for the January release cycle? For the 13.01 my plan was to stay at 3.7 plus the stable 3.7.y updates (as by the time of code freeze the mainline would be at v3.8-rc4 or so - not sure if -rc4 would be stable enough). But if the topic owners fill comfortable with moving to 3.8, we can go that way. Just would like to get confirmations from the owners of the heaviest topics. For my part I have prepared a 3.8 branch for vexpress [1] which doesn't yet contain Android patches or bit.LITTLE MP as their respective branches aren't on 3.8 yet. big.LITTLE MP is 3.8 based now :) I take it as the vexpress topic (for the ll tree) and the big.LITTLE topic (for the llct tree) are ready to switch to 3.8, correct? This leaves the Android topic for llct (John?) and Samsung LT topic for ll (Tushar?). I am ok with 3.8 migration. Samsung LT tree would be available around -rc3 time. Thanks, Andrey -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [ANNOUNCE] linux-linaro kernel schedule for 12.12
On 12/13/2012 02:14 AM, Andrey Konovalov wrote: Greetings, The ll tree has been updated to use llct-20121211.0 as the base. It still has just the ARM LT topic; waiting for the v3.7 based topic from Samsung LT. v3.7 based Samsung LT kernel has been pushed to glo. [1] [1] http://git.linaro.org/gitweb?p=landing-teams/working/samsung/kernel.git;a=shortlog;h=refs/heads/tracking Issues: * Ethernet still broken on Ubuntu. (Same status as 3.7-rc6, interesting Android kernel built from the same source has working ethernet connection.) * Android kernel doesn't compile because of some change in gpu/ion. Even after adding fixes for compilation errors there is crash during booting, so didn't push those fixes. I hope we will have some more time for any critical fixes. Also the hack by Bero to make perf to build on android has been removed: will see if it break the perf build on ubuntu (see the LinuxLinaroKernelSchedule for more details). * December 13 is the last date to update ll for 12.12 * The current status and the schedule is: https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelSchedule Thanks, Andrey On 12/11/2012 01:54 PM, Andrey Konovalov wrote: The llct based on v3.7 release is there, and is tagged llct-20121211.0 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 3/3] netfilter: xt_quota2: Remove extra parameter from netlink_kernel_create
Required as per commit 9f00d9776bc5 (netlink: hide struct module
parameter in netlink_kernel_create).
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
net/netfilter/xt_quota2.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/xt_quota2.c b/net/netfilter/xt_quota2.c
index 3a9c1f9..8163f37 100644
--- a/net/netfilter/xt_quota2.c
+++ b/net/netfilter/xt_quota2.c
@@ -350,14 +350,15 @@ static struct xt_match quota_mt2_reg[] __read_mostly = {
static int __init quota_mt2_init(void)
{
int ret;
+#ifdef CONFIG_NETFILTER_XT_MATCH_QUOTA2_LOG
struct netlink_kernel_cfg cfg = {
.groups = 1,
};
+#endif
pr_debug(xt_quota2: init());
#ifdef CONFIG_NETFILTER_XT_MATCH_QUOTA2_LOG
- nflognl = netlink_kernel_create(init_net, NETLINK_NFLOG,
- THIS_MODULE, cfg);
+ nflognl = netlink_kernel_create(init_net, NETLINK_NFLOG, cfg);
if (!nflognl)
return -ENOMEM;
#endif
--
1.7.4.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 0/3] Fixing build error with android-3.7
Following patches are required on android-3.7 branch for the androidized kernel for Origen to build. Needs testing on USB gadget functionalities. Tushar Behera (3): usb: gadget: android: Fix build error because of removal of usb_gadget_controller_number usb: gadget: android: Fix build error because of change in composite driver framework netfilter: xt_quota2: Remove extra parameter from netlink_kernel_create drivers/usb/gadget/android.c | 18 +- drivers/usb/gadget/composite.c |5 - net/netfilter/xt_quota2.c |5 +++-- 3 files changed, 12 insertions(+), 16 deletions(-) -- 1.7.4.1 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 2/3] usb: gadget: android: Fix build error because of change in composite driver framework
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
drivers/usb/gadget/android.c |7 ---
drivers/usb/gadget/composite.c |5 -
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/gadget/android.c b/drivers/usb/gadget/android.c
index c26d7be..2b11055 100644
--- a/drivers/usb/gadget/android.c
+++ b/drivers/usb/gadget/android.c
@@ -1175,6 +1175,7 @@ static struct usb_composite_driver android_usb_driver = {
.name = android_usb,
.dev= device_desc,
.strings= dev_strings,
+ .bind = android_bind,
.unbind = android_usb_unbind,
.max_speed = USB_SPEED_HIGH,
};
@@ -1291,10 +1292,10 @@ static int __init init(void)
_android_dev = dev;
/* Override composite driver functions */
- composite_driver.setup = android_setup;
- composite_driver.disconnect = android_disconnect;
+ composite_driver_template.setup = android_setup;
+ composite_driver_template.disconnect = android_disconnect;
- return usb_composite_probe(android_usb_driver, android_bind);
+ return usb_composite_probe(android_usb_driver);
}
module_init(init);
diff --git a/drivers/usb/gadget/composite.c b/drivers/usb/gadget/composite.c
index 957f973..c4460a5 100644
--- a/drivers/usb/gadget/composite.c
+++ b/drivers/usb/gadget/composite.c
@@ -1528,8 +1528,11 @@ composite_resume(struct usb_gadget *gadget)
}
/*-*/
-
+#if IS_ENABLED(CONFIG_USB_G_ANDROID)
+static struct usb_gadget_driver composite_driver_template = {
+#else
static const struct usb_gadget_driver composite_driver_template = {
+#endif
.bind = composite_bind,
.unbind = composite_unbind,
--
1.7.4.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 1/3] usb: gadget: android: Fix build error because of removal of usb_gadget_controller_number
Required as per commit ed9cbda (usb: gadget: remove
usb_gadget_controller_number()).
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
drivers/usb/gadget/android.c | 11 +--
1 files changed, 1 insertions(+), 10 deletions(-)
diff --git a/drivers/usb/gadget/android.c b/drivers/usb/gadget/android.c
index d2c3393..c26d7be 100644
--- a/drivers/usb/gadget/android.c
+++ b/drivers/usb/gadget/android.c
@@ -1118,7 +1118,7 @@ static int android_bind(struct usb_composite_dev *cdev)
{
struct android_dev *dev = _android_dev;
struct usb_gadget *gadget = cdev-gadget;
- int gcnum, id, ret;
+ int id, ret;
/*
* Start disconnected. Userspace will connect the gadget once
@@ -1156,15 +1156,6 @@ static int android_bind(struct usb_composite_dev *cdev)
strings_dev[STRING_SERIAL_IDX].id = id;
device_desc.iSerialNumber = id;
- gcnum = usb_gadget_controller_number(gadget);
- if (gcnum = 0)
- device_desc.bcdDevice = cpu_to_le16(0x0200 + gcnum);
- else {
- pr_warning(%s: controller '%s' not recognized\n,
- longname, gadget-name);
- device_desc.bcdDevice = __constant_cpu_to_le16(0x);
- }
-
usb_gadget_set_selfpowered(gadget);
dev-cdev = cdev;
--
1.7.4.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH] gpu: ion: Use RB_CLEAR_NODE instead of rb_init_node
rb_init_node() has been removed from the kernel, use alternate macro. Signed-off-by: Tushar Behera tushar.beh...@linaro.org --- This patch also needs to go into android-3.7 tree. drivers/gpu/ion/ion.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/ion/ion.c b/drivers/gpu/ion/ion.c index 1002ec0..baab410 100644 --- a/drivers/gpu/ion/ion.c +++ b/drivers/gpu/ion/ion.c @@ -191,7 +191,7 @@ static struct ion_handle *ion_handle_create(struct ion_client *client, if (!handle) return ERR_PTR(-ENOMEM); kref_init(handle-ref); - rb_init_node(handle-node); + RB_CLEAR_NODE(handle-node); handle-client = client; ion_buffer_get(buffer); handle-buffer = buffer; -- 1.7.4.1 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Add board config fragments to llct? (Re: Would like to add couple conf files to the config-boards-tracking branch)
On 11/15/2012 06:05 PM, Jon Medhurst (Tixy) wrote: On Thu, 2012-11-15 at 11:37 +, Jon Medhurst (Tixy) wrote: On Thu, 2012-11-15 at 09:20 +0530, Tushar Behera wrote: On 11/14/2012 07:41 PM, Ryan Harkin wrote: On 14 November 2012 11:38, Jon Medhurst (Tixy) t...@linaro.org wrote: [...] Now that the LT branches included in linux-linaro (ll) are based on llct, then they could modify the board configs in llct if required for the work in their topics. So at the moment, I can't think of a good reason not to pub all the board configs into llct. Can anyone else? I don't know if we need the board configs to be sourced from a single repo, or allow board configs to be included in llct from LT trees. One central repo means that people know where to go This seems like the easiest option to me. Let's do it this way unless someone gives a valid objection. (Unless we had an official maintainer to manage all commits to the tree.) I assume this would have to be Andrey. Andrey, are you OK with that? Or does someone else need to do it? Each LT that is using LLCT would have to send a patch to get their config updated. So long as this happens in a timely manner, LTs should be able to live with that process. I suppose we are talking about the basic board config here. That should be ok. The new board enablement config fragments should always go in with the respective topic branches. I agree. Of course, this can't be done until Linaro's CI jobs and Ubuntu kernel packaging jobs support multiple config fragments, so for now we're stuck with one config per board. Shall we agree that all of these will live in the central location of the config-boards-tracking branch of git://git.linaro.org/kernel/configs.git ? Fine with me as long as the basic board config gets pulled into llct. I will post the Origen patch today. -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Add board config fragments to llct? (Re: Would like to add couple conf files to the config-boards-tracking branch)
On 11/15/2012 05:31 PM, Ryan Harkin wrote: On 15 November 2012 11:37, Jon Medhurst (Tixy) t...@linaro.org wrote: On Thu, 2012-11-15 at 09:20 +0530, Tushar Behera wrote: On 11/14/2012 07:41 PM, Ryan Harkin wrote: On 14 November 2012 11:38, Jon Medhurst (Tixy) t...@linaro.org wrote: [...] Now that the LT branches included in linux-linaro (ll) are based on llct, then they could modify the board configs in llct if required for the work in their topics. So at the moment, I can't think of a good reason not to pub all the board configs into llct. Can anyone else? I don't know if we need the board configs to be sourced from a single repo, or allow board configs to be included in llct from LT trees. One central repo means that people know where to go This seems like the easiest option to me. Let's do it this way unless someone gives a valid objection. (Unless we had an official maintainer to manage all commits to the tree.) I assume this would have to be Andrey. Andrey, are you OK with that? Or does someone else need to do it? Each LT that is using LLCT would have to send a patch to get their config updated. So long as this happens in a timely manner, LTs should be able to live with that process. I suppose we are talking about the basic board config here. That should be ok. The new board enablement config fragments should always go in with the respective topic branches. I agree. OK, can we do it then? We're freezing for release today, but it's not a big change, so we can get it in, right? At some point in the past, Andrey asked: My question is if this topic branch would be kernel/configs.git, Sounds perfect config-boards-tracking branch or something else? I don't have an opinion. We'll probably have to live with it for a long time, but as long as it looks sensible, I'm sure people will be ok... config-boards-tracking branch already has got config fragment for Origen board, but this config file has enabled all the config options used in all the topic branches too. If we plan to keep it that way, I suggest to add the basic board config file to config-core-tracking. (It makes sense as we would be enabling only mainline components that is essential to boot the board). Any further modification to these can always be done through LT topic branches. Andrey, let me know which way you would prefer the patch? -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Add board config fragments to llct? (Re: Would like to add couple conf files to the config-boards-tracking branch)
On 11/14/2012 07:41 PM, Ryan Harkin wrote: On 14 November 2012 11:38, Jon Medhurst (Tixy) t...@linaro.org wrote: Adding linaro-dev list and replying with some comments... On Tue, 2012-11-13 at 20:20 +0400, Andrey Konovalov wrote: The llct tree itself has no suitable .conf or defconfig for vexpress at all. That's the problem (wrt the ci jobs). The easier way seemed to be a single kernel/configs.git, config-boards-tracking branch to provide the config fragments for all the llct jobs. But it creates several instances of the same board.conf files and adds confusion. Agreed. Should we do in the jenkins jobs something like 'git checkout arm_lt/integration-linaro-vexpress.conf -- linaro/configs/vexpress.conf' for vexpress and similar (but different and unique) command for the other boards? Yes, I see the problem. But getting CI jobs to pull configs direct from an LT tree seems like the wrong solution. I guess what people really need is configs in linux-linaro-core-tracking (llct) (I'm sure people have told me that before and I possibly didn't listen enough). Now that the LT branches included in linux-linaro (ll) are based on llct, then they could modify the board configs in llct if required for the work in their topics. So at the moment, I can't think of a good reason not to pub all the board configs into llct. Can anyone else? I don't know if we need the board configs to be sourced from a single repo, or allow board configs to be included in llct from LT trees. One central repo means that people know where to go This seems like the easiest option to me. Let's do it this way unless someone gives a valid objection. (Unless we had an official maintainer to manage all commits to the tree.) I assume this would have to be Andrey. Andrey, are you OK with that? Or does someone else need to do it? Each LT that is using LLCT would have to send a patch to get their config updated. So long as this happens in a timely manner, LTs should be able to live with that process. I suppose we are talking about the basic board config here. That should be ok. The new board enablement config fragments should always go in with the respective topic branches. Or course, once Linaro's build and test infrastructure supports config fragments fully, then we could have have separate config fragments for - basic board config - new board enablement - special features (e.g. big.LITTLE MP) - testing or benchmarking config and the configs could live in the tree relevant to the code they apply to rather than having a single central board config we have to manage. That sounds scarey - there would be no one place to get a config, but I guess, if you need a config for feature X, you'd also need the branch for feature X that contained the source and config, so it would work out fine. Cheers, Ryan. ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: linux-linaro kernel trees move to 3.7 and 12.11 schedule
On 11/07/2012 01:40 AM, Andrey Konovalov wrote: Greetings, This cycle some more attention is given to the shape of the ci builds done from the llct tree (the ones with llct in their name at https://ci.linaro.org/jenkins/view/Linux%20Linaro%20Tracking/). See below. On 10/27/2012 12:39 PM, Andrey Konovalov wrote: The 12.11 linux-linaro kernel release will be v3.7-rc5 or v3.7-rc6 based. Please make sure to update your topics to 3.7. Here is the plan: * October 30: initial v3.7-rc3 based llct build, 3.6 based topics will not be included if there are conflicts Done. The tag is llct-20121101.1. v3.7-rc3 based. Origen failed to boot in LAVA (silence after Uncompressing Linux... done, booting the kernel.) I haven't tested it yet (llct), but it might be because of incorrect serial port number. I have tested v3.7-rc4 kernel with said change in config file, it works. Anyways, I will get back tomorrow after testing llct. mmc doesn't work on Panda when the kernel is built using the (old) config fragments (http://validation.linaro.org/lava-server/scheduler/job/37832/log_file). Panda boots ok with omap2plus_defconfig. vexpress boots ok. * November 6: updated big-LITTLE-MP topic arrives, llct rebuild (llct-20121106) Done. The tag is llct-20121106.0. v3.7-rc4 based. Android and big-LITTLE-MP topics are back. New Gator version (v5.12). *ubuntu-sauce topic will be dropped* Anyone objects? The same boot failure for Origen. Disabling device tree in the kernel config makes the kernel to start booting (http://validation.linaro.org/lava-server/scheduler/job/37885/log_file). Could be arch/arm/boot/dts/exynos4210-origen.dts issue. Thanks, Andrey * November 8: linux-linaro (ll) rebuild based on llct-20121106 * November 13: llct rebuild (llct-20121113) * November 15: ll rebuild based on llct-20121113 * November 20: llct rebuild (llct-20121120) * November 22: ll rebuild based on llct-20121120, ll code freeze (no massive ll topics updates after that; bugfixes only) (The dates above are milestones, there will be additional llct/ll rebuilds on other dates as well) The config fragment branches to be used in 12.11: git://git.linaro.org/kernel/configs.git , config-core-tracking and config-boards-tracking branches. Thanks, Andrey ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Planning topcs for inclusion in linux-linaro
On 17 October 2012 21:26, Andrey Konovalov andrey.konova...@linaro.org wrote: On 10/17/2012 10:41 AM, Tushar Behera wrote: On 10/06/2012 02:37 AM, Andrey Konovalov wrote: Greetings, Minor change to the plan: * The current llct is *llct-20121006.0* * October 9: ll rebuild based on llct-20121006.0 * October 16: ll rebuild based on llct-20121012.N, ll code freeze (no massive ll topics updates after that; bugfixes only) Samsung LT kernel tree based on llct-20121012.0 has been pushed to g.l.o. git://git.linaro.org/landing-teams/working/samsung/kernel.git branch: tracking tag: samsung-lt-v3.6-1 Let me know if there are issues after building linux-linaro tree. I would be out of office for rest of the week and would be checking the mails on coming Monday. I've created ll-20121017.0 using the updated Samsung LT's tracking topic. The difference from the previous topic version is dropping the two commits: UBUNTU: dm-raid4-5: Fix compilation warning and CONFIG: ORIGEN: ANDROID: Disable HDMI/FIMC temporarily I've restored the UBUNTU: dm-raid4-5: Fix compilation warning one, as it seems to be the correct fix. Thanks. This patch needs to picked up in ubuntu-sauce branch. So the resulting difference between ll-20121016.0 and ll-20121017.0 is just the android_origen_defconfig change: That is right. diff --git a/arch/arm/configs/android_origen_defconfig b/arch/arm/configs/android_origen_defconfig index d04cf03..869183e 100644 --- a/arch/arm/configs/android_origen_defconfig +++ b/arch/arm/configs/android_origen_defconfig @@ -125,6 +125,11 @@ CONFIG_VIDEO_S5K4ECGX_SLSI_4EC=y CONFIG_V4L_PLATFORM_DRIVERS=y CONFIG_V4L_USB_DRIVERS=y CONFIG_VIDEO_SAMSUNG_S5P_FIMC=y +CONFIG_VIDEO_S5P_FIMC=y +CONFIG_VIDEO_SAMSUNG_S5P_TV=y +CONFIG_VIDEO_SAMSUNG_S5P_HDMI=y +CONFIG_VIDEO_SAMSUNG_S5P_SDO=y +CONFIG_VIDEO_SAMSUNG_S5P_MIXER=y CONFIG_V4L_MEM2MEM_DRIVERS=y CONFIG_VIDEO_SAMSUNG_S5P_G2D=y CONFIG_VIDEO_SAMSUNG_S5P_JPEG=y Thanks, Andrey On 10/05/2012 05:25 PM, Jon Medhurst (Tixy) wrote: On Fri, 2012-10-05 at 17:03 +0400, Andrey Konovalov wrote: On 10/05/2012 12:12 PM, Jon Medhurst (Tixy) wrote: On Thu, 2012-10-04 at 23:02 +0400, Andrey Konovalov wrote: don't we need some kind of notification system where you announce a plan to rebuild linux-linaro and give us a version of llct to base our LT branches off? Yes, this makes sense. Would the following plan be OK: (N should normally be 0, but may be a small positive number) * till the end of this week please use llct-20121004.0 as the base for the linux-linaro (ll) topics * October 9: ll rebuild based on llct-20121005.N * October 16: ll rebuild based on llct-20121012.N * October 23: ll rebuild based on llct-20121019.N, ll code freeze (no massive ll topics updates after that; bugfixes only) Is this month following the normal release cycle? If so, isn't the release day Oct 24th, and release candidates are built from the previous Thurday's code, i.e. Oct 18th. I.e. the freeze for the release should be Oct 16th not 23rd? Oops.. Your are right. Why don't we have the Thursday, October 32 this year? So the correct plan is the following: * till the end of this week please use llct-20121004.0 as the base for the linux-linaro (ll) topics * October 9: ll rebuild based on llct-20121005.N * October 16: ll rebuild based on llct-20121012.N, ll code freeze (no massive ll topics updates after that; bugfixes only) Also, I assume we're not going to try to move to Linux 3.7 this month? That's correct. We didn't have the kernel.org release based (vs -rc based) ll release for quite a while. And the plan is to stick to v3.6 for 12.10 release unless someone needs to move to v3.7-rc* by all means this cycle. After October 19 the llct tree will move to v3.7-rc*, but the ll tree will be frozen till the 12.10 is out. That all sounds reasonable to me. -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Planning topcs for inclusion in linux-linaro
On 10/06/2012 02:37 AM, Andrey Konovalov wrote: Greetings, Minor change to the plan: * The current llct is *llct-20121006.0* * October 9: ll rebuild based on llct-20121006.0 * October 16: ll rebuild based on llct-20121012.N, ll code freeze (no massive ll topics updates after that; bugfixes only) Samsung LT kernel tree based on llct-20121012.0 has been pushed to g.l.o. git://git.linaro.org/landing-teams/working/samsung/kernel.git branch: tracking tag: samsung-lt-v3.6-1 Let me know if there are issues after building linux-linaro tree. I would be out of office for rest of the week and would be checking the mails on coming Monday. Thanks, Andrey On 10/05/2012 05:25 PM, Jon Medhurst (Tixy) wrote: On Fri, 2012-10-05 at 17:03 +0400, Andrey Konovalov wrote: On 10/05/2012 12:12 PM, Jon Medhurst (Tixy) wrote: On Thu, 2012-10-04 at 23:02 +0400, Andrey Konovalov wrote: don't we need some kind of notification system where you announce a plan to rebuild linux-linaro and give us a version of llct to base our LT branches off? Yes, this makes sense. Would the following plan be OK: (N should normally be 0, but may be a small positive number) * till the end of this week please use llct-20121004.0 as the base for the linux-linaro (ll) topics * October 9: ll rebuild based on llct-20121005.N * October 16: ll rebuild based on llct-20121012.N * October 23: ll rebuild based on llct-20121019.N, ll code freeze (no massive ll topics updates after that; bugfixes only) Is this month following the normal release cycle? If so, isn't the release day Oct 24th, and release candidates are built from the previous Thurday's code, i.e. Oct 18th. I.e. the freeze for the release should be Oct 16th not 23rd? Oops.. Your are right. Why don't we have the Thursday, October 32 this year? So the correct plan is the following: * till the end of this week please use llct-20121004.0 as the base for the linux-linaro (ll) topics * October 9: ll rebuild based on llct-20121005.N * October 16: ll rebuild based on llct-20121012.N, ll code freeze (no massive ll topics updates after that; bugfixes only) Also, I assume we're not going to try to move to Linux 3.7 this month? That's correct. We didn't have the kernel.org release based (vs -rc based) ll release for quite a while. And the plan is to stick to v3.6 for 12.10 release unless someone needs to move to v3.7-rc* by all means this cycle. After October 19 the llct tree will move to v3.7-rc*, but the ll tree will be frozen till the 12.10 is out. That all sounds reasonable to me. -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Planning topcs for inclusion in linux-linaro
On 10/06/2012 02:37 AM, Andrey Konovalov wrote: Greetings, Minor change to the plan: * The current llct is *llct-20121006.0* * October 9: ll rebuild based on llct-20121006.0 * October 16: ll rebuild based on llct-20121012.N, ll code freeze (no massive ll topics updates after that; bugfixes only) I am not in office during this week, so won't be able to update the kernel. Current Samsung LT kernel is based on llct-20121004.0. I will be updating this to llct-20121012.N next. Thanks, Andrey On 10/05/2012 05:25 PM, Jon Medhurst (Tixy) wrote: On Fri, 2012-10-05 at 17:03 +0400, Andrey Konovalov wrote: On 10/05/2012 12:12 PM, Jon Medhurst (Tixy) wrote: On Thu, 2012-10-04 at 23:02 +0400, Andrey Konovalov wrote: don't we need some kind of notification system where you announce a plan to rebuild linux-linaro and give us a version of llct to base our LT branches off? Yes, this makes sense. Would the following plan be OK: (N should normally be 0, but may be a small positive number) * till the end of this week please use llct-20121004.0 as the base for the linux-linaro (ll) topics * October 9: ll rebuild based on llct-20121005.N * October 16: ll rebuild based on llct-20121012.N * October 23: ll rebuild based on llct-20121019.N, ll code freeze (no massive ll topics updates after that; bugfixes only) Is this month following the normal release cycle? If so, isn't the release day Oct 24th, and release candidates are built from the previous Thurday's code, i.e. Oct 18th. I.e. the freeze for the release should be Oct 16th not 23rd? Oops.. Your are right. Why don't we have the Thursday, October 32 this year? So the correct plan is the following: * till the end of this week please use llct-20121004.0 as the base for the linux-linaro (ll) topics * October 9: ll rebuild based on llct-20121005.N * October 16: ll rebuild based on llct-20121012.N, ll code freeze (no massive ll topics updates after that; bugfixes only) Also, I assume we're not going to try to move to Linux 3.7 this month? That's correct. We didn't have the kernel.org release based (vs -rc based) ll release for quite a while. And the plan is to stick to v3.6 for 12.10 release unless someone needs to move to v3.7-rc* by all means this cycle. After October 19 the llct tree will move to v3.7-rc*, but the ll tree will be frozen till the 12.10 is out. That all sounds reasonable to me. -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Planning topcs for inclusion in linux-linaro
On 10/05/2012 01:42 PM, Jon Medhurst (Tixy) wrote: On Thu, 2012-10-04 at 23:02 +0400, Andrey Konovalov wrote: don't we need some kind of notification system where you announce a plan to rebuild linux-linaro and give us a version of llct to base our LT branches off? Yes, this makes sense. Would the following plan be OK: (N should normally be 0, but may be a small positive number) * till the end of this week please use llct-20121004.0 as the base for the linux-linaro (ll) topics * October 9: ll rebuild based on llct-20121005.N * October 16: ll rebuild based on llct-20121012.N * October 23: ll rebuild based on llct-20121019.N, ll code freeze (no massive ll topics updates after that; bugfixes only) Is this month following the normal release cycle? If so, isn't the release day Oct 24th, and release candidates are built from the previous Thurday's code, i.e. Oct 18th. I.e. the freeze for the release should be Oct 16th not 23rd? Also, I assume we're not going to try to move to Linux 3.7 this month? Samsung LT release would be based on Linux-v3.6 final release, no plans to move to 3.7 during 12.10. -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 0/3] kbuild modifications to print git commit ID
The bootlog in Ubuntu/Android images provide minimal information about the current HEAD from which the kernel was built. This patchset enables us to get detailed version info of the kernel. Tested both on Ubuntu and Android images. Patch 1 is already submitted to kernel-build ML and has been rejected. Hence review of this patchset is required w.r.t. Android/Ubuntu LEB and linux-linaro in mind. Tushar Behera (3): kbuild: setlocalversion: ignore private tags while reporting local version kbuild: Add support to extract information about current git commit HEAD init: Add additional print for detailed kernel version Makefile|7 +-- include/linux/printk.h |1 + init/main.c |3 +++ init/version.c |3 +++ scripts/setlocalversion |5 +++-- 5 files changed, 15 insertions(+), 4 deletions(-) -- 1.7.4.1 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 2/3] kbuild: Add support to extract information about current git commit HEAD
Signed-off-by: Tushar Behera tushar.beh...@linaro.org --- Makefile |7 +-- 1 files changed, 5 insertions(+), 2 deletions(-) diff --git a/Makefile b/Makefile index 0f66f14..7e83768 100644 --- a/Makefile +++ b/Makefile @@ -374,6 +374,7 @@ KBUILD_LDFLAGS_MODULE := -T $(srctree)/scripts/module-common.lds # Read KERNELRELEASE from include/config/kernel.release (if it exists) KERNELRELEASE = $(shell cat include/config/kernel.release 2 /dev/null) KERNELVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if $(SUBLEVEL),.$(SUBLEVEL)))$(EXTRAVERSION) +KERNELVERSIONLOCAL= $(shell cat .scmversion 2 /dev/null) export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION export ARCH SRCARCH CONFIG_SHELL HOSTCC HOSTCFLAGS CROSS_COMPILE AS LD CC @@ -778,7 +779,8 @@ $(vmlinux-dirs): prepare scripts include/config/kernel.release: include/config/auto.conf FORCE $(Q)rm -f $@ $(Q)echo $(KERNELVERSION)$$($(CONFIG_SHELL) $(srctree)/scripts/setlocalversion $(srctree)) $@ - + $(Q)rm -f .scmversion + $(Q)($(CONFIG_SHELL) $(srctree)/scripts/setlocalversion --save-scmversion $(srctree)) # Things we need to do before we recursively start building the kernel # or the modules are listed in prepare. @@ -829,7 +831,8 @@ define filechk_utsrelease.h echo '$(KERNELRELEASE) exceeds $(uts_len) characters' 2;\ exit 1; \ fi; \ - (echo \#define UTS_RELEASE \$(KERNELRELEASE)\;) + (echo \#define UTS_RELEASE \$(KERNELRELEASE)\; \ + echo \#define KERNEL_VERSION_LOCAL \$(KERNELVERSIONLOCAL)\;) endef define filechk_version.h -- 1.7.4.1 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 3/3] init: Add additional print for detailed kernel version
When CONFIG_LOCALVERSION_AUTO is not defined, kernel boot log prints
only short version. This doesn't have any information regarding the
commit at which the kernel was compiled.
Adding an additional print statement to explicitly tell the current
HEAD.
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
include/linux/printk.h |1 +
init/main.c|3 +++
init/version.c |3 +++
3 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/include/linux/printk.h b/include/linux/printk.h
index 9afc01e..a2560f6 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -6,6 +6,7 @@
extern const char linux_banner[];
extern const char linux_proc_banner[];
+extern const char linux_scm_version_banner[];
static inline int printk_get_level(const char *buffer)
{
diff --git a/init/main.c b/init/main.c
index b286730..bad6b9b 100644
--- a/init/main.c
+++ b/init/main.c
@@ -494,6 +494,9 @@ asmlinkage void __init start_kernel(void)
boot_cpu_init();
page_address_init();
printk(KERN_NOTICE %s, linux_banner);
+#if !IS_ENABLED(CONFIG_LOCALVERSION_AUTO)
+ printk(KERN_NOTICE %s, linux_scm_version_banner);
+#endif
setup_arch(command_line);
mm_init_owner(init_mm, init_task);
mm_init_cpumask(init_mm);
diff --git a/init/version.c b/init/version.c
index 86fe0cc..e86cce9 100644
--- a/init/version.c
+++ b/init/version.c
@@ -46,3 +46,6 @@ const char linux_proc_banner[] =
%s version %s
( LINUX_COMPILE_BY @ LINUX_COMPILE_HOST )
( LINUX_COMPILER ) %s\n;
+
+const char linux_scm_version_banner [] =
+ Detailed version Linux UTS_RELEASE KERNEL_VERSION_LOCAL \n;
--
1.7.4.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH] linaro/configs: ubuntu: Disable support for generic OHCI platform driver
OHCI-HCD driver does not support multiple SoC drivers during the compile time. Hence the generic driver should be disabled in ubuntu.conf and related OHCI Soc drivers should be enabled in respective board config files. Signed-off-by: Tushar Behera tushar.beh...@linaro.org --- linaro/configs/ubuntu.conf |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/linaro/configs/ubuntu.conf b/linaro/configs/ubuntu.conf index 5d0a372..88e58df 100644 --- a/linaro/configs/ubuntu.conf +++ b/linaro/configs/ubuntu.conf @@ -1556,7 +1556,6 @@ CONFIG_USB_OXU210HP_HCD=m CONFIG_USB_ISP116X_HCD=m CONFIG_USB_ISP1760_HCD=m CONFIG_USB_OHCI_HCD=y -CONFIG_USB_OHCI_HCD_PLATFORM=y CONFIG_USB_OHCI_LITTLE_ENDIAN=y CONFIG_USB_U132_HCD=m CONFIG_USB_SL811_HCD=m -- 1.7.4.1 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 2/2] UBUNTU: dm-raid4-5: Fix compilation warning
Fixes following compilation warning.
ubuntu/dm-raid4-5/dm-raid4-5.c:4505:2: warning: initialization from
incompatible pointer type [enabled by default]
ubuntu/dm-raid4-5/dm-raid4-5.c:4505:2: warning: (near initialization for
‘raid_target.status’) [enabled by default]
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
ubuntu/dm-raid4-5/dm-raid4-5.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/ubuntu/dm-raid4-5/dm-raid4-5.c b/ubuntu/dm-raid4-5/dm-raid4-5.c
index e69ab44..9f55f58 100644
--- a/ubuntu/dm-raid4-5/dm-raid4-5.c
+++ b/ubuntu/dm-raid4-5/dm-raid4-5.c
@@ -4246,7 +4246,7 @@ static void raid_devel_stats(struct dm_target *ti, char
*result,
}
static int raid_status(struct dm_target *ti, status_type_t type,
- char *result, unsigned maxlen)
+ unsigned status_flags, char *result, unsigned maxlen)
{
unsigned p, sz = 0;
char buf[BDEVNAME_SIZE];
--
1.7.4.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 1/2] UBUNTU: dm-raid4-5: rename split_io to max_io_len
Commit 542f90381422 (dm: support non power of two target max_io_len) renames struct dm_target:split_io variable to max_io_len. Signed-off-by: Tushar Behera tushar.beh...@linaro.org --- ubuntu/dm-raid4-5/dm-raid4-5.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/ubuntu/dm-raid4-5/dm-raid4-5.c b/ubuntu/dm-raid4-5/dm-raid4-5.c index e05b0e1..e69ab44 100644 --- a/ubuntu/dm-raid4-5/dm-raid4-5.c +++ b/ubuntu/dm-raid4-5/dm-raid4-5.c @@ -4073,7 +4073,7 @@ static int raid_ctr(struct dm_target *ti, unsigned argc, char **argv) * Make sure that dm core only hands maximum io size * length down and pays attention to io boundaries. */ - ti-split_io = rs-set.io_size; + ti-max_io_len = rs-set.io_size; ti-private = rs; /* Initialize work queue to handle this RAID set's io. */ -- 1.7.4.1 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 0/2] Android fixes w.r.t. 3.6 kernel
Ping !!! On 08/31/2012 09:57 AM, Tushar Behera wrote: Required for android-3.6 tree. Tushar Behera (2): netfilter: xt_quota2: Move away from NLMSG_PUT() netfilter: xt_quota2: Update parameter list in netlink_kernel_create net/netfilter/xt_quota2.c | 25 - 1 files changed, 16 insertions(+), 9 deletions(-) Without these patches, build of LT kernel based on llct(v3.6-rc5) fails with following error message. net/netfilter/xt_quota2.c: In function ‘quota2_log’: net/netfilter/xt_quota2.c:85:2: error: implicit declaration of function ‘NLMSG_PUT’ [-Werror=implicit-function-declaration] net/netfilter/xt_quota2.c:85:6: warning: assignment makes pointer from integer without a cast [enabled by default] net/netfilter/xt_quota2.c:110:1: warning: label ‘nlmsg_failure’ defined but not used [-Wunused-label] net/netfilter/xt_quota2.c: In function ‘quota_mt2_init’: net/netfilter/xt_quota2.c:353:12: warning: passing argument 3 of ‘netlink_kernel_create’ makes pointer from integer without a cast [enabled by default] In file included from include/linux/if_link.h:5:0, from include/linux/netdevice.h:31, from include/linux/netfilter/x_tables.h:188, from net/netfilter/xt_quota2.c:21: include/linux/netlink.h:185:21: note: expected ‘struct module *’ but argument is of type ‘int’ net/netfilter/xt_quota2.c:353:12: error: too many arguments to function ‘netlink_kernel_create’ In file included from include/linux/if_link.h:5:0, from include/linux/netdevice.h:31, from include/linux/netfilter/x_tables.h:188, from net/netfilter/xt_quota2.c:21: include/linux/netlink.h:185:21: note: declared here -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 1/2] netfilter: xt_quota2: Move away from NLMSG_PUT()
Commit c3deafc5261a (netlink: Delete NLMSG_PUT and NLMSG_NEW.) removes
NLMSG_PUT() and recommends use of nlmsg_put() instead.
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
net/netfilter/xt_quota2.c | 17 +++--
1 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/net/netfilter/xt_quota2.c b/net/netfilter/xt_quota2.c
index fb2ef46..865f909 100644
--- a/net/netfilter/xt_quota2.c
+++ b/net/netfilter/xt_quota2.c
@@ -24,6 +24,8 @@
#include linux/netfilter_ipv4/ipt_ULOG.h
#endif
+#include net/netlink.h
+
/**
* @lock: lock to protect quota writers from each other
*/
@@ -82,9 +84,15 @@ static void quota2_log(unsigned int hooknum,
}
/* NLMSG_PUT() uses goto nlmsg_failure */
- nlh = NLMSG_PUT(log_skb, /*pid*/0, /*seq*/0, qlog_nl_event,
- sizeof(*pm));
- pm = NLMSG_DATA(nlh);
+ nlh = nlmsg_put(log_skb, /*pid*/0, /*seq*/0, qlog_nl_event,
+ sizeof(*pm), 0);
+
+ if (!nlh) {
+ pr_debug(xt_quota2: error during NLMSG_PUT\n);
+ return;
+ }
+
+ pm = nlmsg_data(nlh);
if (skb-tstamp.tv64 == 0)
__net_timestamp((struct sk_buff *)skb);
pm-data_len = 0;
@@ -106,9 +114,6 @@ static void quota2_log(unsigned int hooknum,
NETLINK_CB(log_skb).dst_group = 1;
pr_debug(throwing 1 packets to netlink group 1\n);
netlink_broadcast(nflognl, log_skb, 0, 1, GFP_ATOMIC);
-
-nlmsg_failure: /* Used within NLMSG_PUT() */
- pr_debug(xt_quota2: error during NLMSG_PUT\n);
}
#else
static void quota2_log(unsigned int hooknum,
--
1.7.4.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 0/2] Android fixes w.r.t. 3.6 kernel
Required for android-3.6 tree. Tushar Behera (2): netfilter: xt_quota2: Move away from NLMSG_PUT() netfilter: xt_quota2: Update parameter list in netlink_kernel_create net/netfilter/xt_quota2.c | 25 - 1 files changed, 16 insertions(+), 9 deletions(-) -- 1.7.4.1 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 2/2] netfilter: xt_quota2: Update parameter list in netlink_kernel_create
Commit a31f2d17b331 (netlink: add netlink_kernel_cfg parameter to
netlink_kernel_create) modifies parameter list of netlink_kernel_create.
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
net/netfilter/xt_quota2.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/net/netfilter/xt_quota2.c b/net/netfilter/xt_quota2.c
index 865f909..3a9c1f9 100644
--- a/net/netfilter/xt_quota2.c
+++ b/net/netfilter/xt_quota2.c
@@ -350,12 +350,14 @@ static struct xt_match quota_mt2_reg[] __read_mostly = {
static int __init quota_mt2_init(void)
{
int ret;
+ struct netlink_kernel_cfg cfg = {
+ .groups = 1,
+ };
pr_debug(xt_quota2: init());
#ifdef CONFIG_NETFILTER_XT_MATCH_QUOTA2_LOG
- nflognl = netlink_kernel_create(init_net,
- NETLINK_NFLOG, 1, NULL,
- NULL, THIS_MODULE);
+ nflognl = netlink_kernel_create(init_net, NETLINK_NFLOG,
+ THIS_MODULE, cfg);
if (!nflognl)
return -ENOMEM;
#endif
--
1.7.4.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: New fast models device-tree topic for linux-linaro
On 08/16/2012 08:24 AM, Tushar Behera wrote: On 08/16/2012 12:55 AM, Andrey Konovalov wrote: On 08/15/2012 08:47 PM, Jon Medhurst (Tixy) wrote: Hi Andrey Can you include a new topic to linux-linaro which contains device-tree files for ARM's fast models? This branch is tracking-armlt-rtsm [1] in the ARM LT working tree. Done, thanks! The git tag is ll-20120815.0. *Tushar*, I've commented out the Samsung LT's topics this time, as they seem to be v3.5-rc2 based. Do you have a plan to move them to v3.6-rc*? v3.6-rc1 based kernel is almost ready, pending some tests. I hope to push it to glo by this Friday. Pushed to [1] with tag *samsung-lt-v3.6-rc1* [1] git://git.linaro.org/landing-teams/working/samsung/kernel.git Thanks, Andrey Thanks For those interested... These device-trees enable the the current Linaro vexpress kernel to boot on fast-models when used with the boot-wrapper at [2], this includes having a working display. However, on the big.LITLE models the A7 cores don't start, giving Failed to boot -38. -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Reboot call fails in cpu_v7_proc_fin()
On 08/15/2012 11:05 AM, Koteswararao Nelakurthi wrote:
Hi,
While executing reboot call on my ARMv7 board, the system hangs during
cpu_proc_fin() call.
Commenting out this line of code, the reboot works properly.
Index: mvlinux/arch/arm/mm/proc-v7.S
===
--- mvlinux.orig/arch/arm/mm/proc-v7.S 2012-08-15 14:12:50.396190110 +0900
+++ mvlinux/arch/arm/mm/proc-v7.S 2012-08-15 14:21:28.730760416 +0900
@@ -51,7 +51,7 @@
mrc p15, 0, r0, c1, c0, 0 @ ctrl register
bic r0, r0, #0x1000 @ ...i
bic r0, r0, #0x0006 @ .ca.
- mcr p15, 0, r0, c1, c0, 0 @ disable caches
+ #mcrp15, 0, r0, c1, c0, 0 @ disable caches
ldmfd sp!, {pc}
ENDPROC(cpu_v7_proc_fin)
is it a CPU_V7 specific issue?
Please provide your valuable input to fix the issue.
Any hint also..will help me in debugging further in this issue.
I have seen above fix in one of the linaro mailing list.
Regards,
koteswararao.
I don't think there is any issue with cpu_v7_proc_fin. In case of the
issue that I was facing, it was fixed by adding a proper reset hook to
my platform.
Please go through following link. I hope that would help.
http://www.mail-archive.com/linux-samsung-soc@vger.kernel.org/msg06170.html
--
Tushar Behera
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: New fast models device-tree topic for linux-linaro
On 08/16/2012 12:55 AM, Andrey Konovalov wrote: On 08/15/2012 08:47 PM, Jon Medhurst (Tixy) wrote: Hi Andrey Can you include a new topic to linux-linaro which contains device-tree files for ARM's fast models? This branch is tracking-armlt-rtsm [1] in the ARM LT working tree. Done, thanks! The git tag is ll-20120815.0. *Tushar*, I've commented out the Samsung LT's topics this time, as they seem to be v3.5-rc2 based. Do you have a plan to move them to v3.6-rc*? v3.6-rc1 based kernel is almost ready, pending some tests. I hope to push it to glo by this Friday. Thanks, Andrey Thanks For those interested... These device-trees enable the the current Linaro vexpress kernel to boot on fast-models when used with the boot-wrapper at [2], this includes having a working display. However, on the big.LITLE models the A7 cores don't start, giving Failed to boot -38. -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Call for topics for the 12.06 linux-linaro* trees
On 06/08/2012 07:30 PM, Andy Green wrote: On 06/08/2012 08:25 PM, the mail apparently from Andrey Konovalov included: Greetings, There will be three linux-linaro trees this month. Also some LTs have moved to 3.5, while the others will stay on older kernels. In addition to linux-linaro-core-tracking and linux-linaro ones (described under https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelTreeProcess), linux-linaro-tracking tree will be created as a merge of the tracking trees of TI (v3.4 based) and Samsung (currently v3.4-rc7 based) LTs. I would be publishing 3.4 based Samsung Kernel today. So, you can use that in linux-linaro-tracking. For reference the TI + Samsung trees I did during Connect can be found here: http://git.linaro.org/gitweb?p=landing-teams/working/ti/kernel.git;a=shortlog;h=refs/heads/unify-samsung-ti This builds and works for OMAP at least. Probably more LT tracking trees would be added, but I am not sure due to the different bases the others use. Each LT's tracking tree act as a topic here, so the call for topics doesn't apply to this tree. linux-linaro-core-tracking tree is moving to 3.5 (but not published at git.linaro.org yet). For those using the 3.4, llct_3.4 branch has been created. This is a copy of the most recent v3.4 based linux-linaro-core-tracking tree. *New generic (not board specific) topics and updates to the existing topics are welcomed for the 3.5 based linux-linaro-core-tracking tree* The requirements for a topic can be found here: https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelTreeProcess#Adding_a_topic_to_linux-linaro_kernel_and_maintaining_it The current topics are: * arm_soc/testing/multiplatform * svenkatr/ufs-for-linux-linaro * svenkatr/emmc-for-linux-linaro * amitdanielk/thermal_exynos4_imx6_work Not sure if this will now already have it, but this patch http://www.mail-archive.com/linux-omap@vger.kernel.org/msg63852.html is important for OMAP... thanks to Tushar for digging up the context of it for us. We're carrying a replica of it in our tracking atm but since what was tracking-thermal_exynos4_imx6-3.4-2012.05 had just one of the pair of patches in older llct, it should be improved to have both, if it doesn't already with this update. -Andy -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 12.05 linux-linaro kernel tree
On 05/18/2012 10:57 PM, Andrey Konovalov wrote:
Samsung LT's topics:
topic/base topic/core topic/bl topic/dt topic/fb topic/pd topic/s2ram
topic/asv_cpufreq topic/led topic/dummy_reg topic/gadget topic/touch
topic/wlan topic/audio topic/hdmi topic/mfc topic/mali
topic/cma_origen topic/android_config topic/ubuntu_config
Attached patch fixes kernel panic while booting Android on Origen board
using linux-linaro kernel. Since this is touching the core file, I would
like to know if there are any objections to this.
Andrey,
If it is ok, you may either apply the patch or merge [1].
[1] git://git.linaro.org/landing-teams/working/samsung/kernel.git
(llt/umm_fixes)
drivers/media/video/videobuf2-dma-contig.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/videobuf2-dma-contig.c
b/drivers/media/video/videobuf2-dma-contig.c
index 266ae7d..57e643b 100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -273,6 +273,9 @@ static struct vm_area_struct *vb2_dc_get_user_vma(
static int vb2_dc_get_user_pages(unsigned long start, struct page **pages,
int n_pages, struct vm_area_struct *vma, int write)
{
+ if (vma-vm_mm == NULL)
+ vma-vm_mm = current-mm;
+
if (vma_is_io(vma)) {
unsigned int i;
--
Tushar Behera
From c579b4d6b17a6fb1b15cc681268db54e5b73afaf Mon Sep 17 00:00:00 2001
From: Sachin Kamat sachin.ka...@linaro.org
Date: Mon, 21 May 2012 13:51:19 +0530
Subject: [PATCH] VB2-DC: Fix Null pointer related kernel boot crash
vma-vm_mm should point to the proper mm structure. But the pointer is
NULL here. Explicitly setting it to current-mm to avoid kernel crash
during bootup.
Signed-off-by: Ritesh Kumar Solanki r.sola...@samsung.com
Signed-off-by: Sachin Kamat sachin.ka...@linaro.org
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
drivers/media/video/videobuf2-dma-contig.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/videobuf2-dma-contig.c b/drivers/media/video/videobuf2-dma-contig.c
index 266ae7d..57e643b 100644
--- a/drivers/media/video/videobuf2-dma-contig.c
+++ b/drivers/media/video/videobuf2-dma-contig.c
@@ -273,6 +273,9 @@ static struct vm_area_struct *vb2_dc_get_user_vma(
static int vb2_dc_get_user_pages(unsigned long start, struct page **pages,
int n_pages, struct vm_area_struct *vma, int write)
{
+ if (vma-vm_mm == NULL)
+ vma-vm_mm = current-mm;
+
if (vma_is_io(vma)) {
unsigned int i;
--
1.7.4.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 12.05 linux-linaro kernel tree
On 05/11/2012 01:04 AM, Andrey Konovalov wrote: Samsung: topic/base topic/core topic/bl topic/dt topic/fb topic/pd topic/s2ram topic/asv_cpufreq topic/led topic/dummy_reg topic/gadget topic/touch topic/wlan topic/audio topic/hdmi topic/mali topic/cma_v24 topic/android_config Following topic branches are available to be pulled to linux-linaro tree. topic/base topic/core topic/bl topic/dt topic/fb topic/pd topic/s2ram topic/asv_cpufreq topic/led topic/dummy_reg topic/gadget topic/touch topic/wlan topic/audio topic/hdmi *topic/mfc* topic/mali *topic/cma_origen* topic/android_config *topic/ubuntu_config* * topic/base is based on v3.4-rc7 and has config patches, both internal and from John's linaro-config-3.4 branch. All other topic branches are based on topic/base. * topic/cma_v24 has been dropped. Instead we have topic/cma_origen that has only Origen specific CMA patches. With this set of patches, I can boot-test Ubuntu and it fails for Android. I will update you if the Android related kernel panic is fixed before 2012.05 release. Please let me know if you run across any issues while merging these branches. Thanks, Andrey ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: New Gator version ready for Linaro kernels / Mali
On 05/17/2012 05:12 AM, Andy Green wrote: On 16/05/12 23:58, Somebody in the thread at some point said: Hi - ARM have released a new version of Developer Studio 5 (DS-5) and we now have a new version of the Gator component [1] to go with this which needs updating in all Linaro kernel trees that will be part of the 12.05 release. For those people maintaining kernel trees here is what this means... - If your kernels are including the linux-linaro-core-tracking [2] branch then you will get the new Gator version from this when it is updated over the next couple of days. You don't need to do anything except to make sure you are up to date with this branch before the 12.05 release. I suspect we'll be issuing tilt-3.3 again, so even though we're on llct for tracking we'll have to revert and update. For those people who have applied Mali driver patches to support profiling by Gator: you don't need to modify those Mali patches, just take the new version of Gator, this will still work OK. Just curious... how many LTs have Mali stuff? If it's more than one, we should perhaps be talking about moving it to linux-linaro-core-tracking. Presumably that then needs coordination about matching userlands in multiple LTs which will need some time. Even if Mali is in good sync today between multiple LTs the architecture of each LT having their own copy of what's meant to be permanently in sync invites problems. True, Mali driver code should move to core part. As of now, Samsung LT is maintaining a version of it, which was part of linux-linaro-2012.04 release. -Andy -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 12.05 linux-linaro kernel tree
On 05/12/2012 11:09 PM, Andrey Konovalov wrote: Tushar, On 05/11/2012 09:04 AM, Tushar Behera wrote: On 05/11/2012 01:04 AM, Andrey Konovalov wrote: Greetings, So far I wasn't updating the linux-linaro tree since the 12.04 release. (The generic topic updates were being done to the linux-linaro-core-tracking tree) Now it is time to move the focus to the linux-linaro tree. For one week it will use the mainline tip as the base. Then, on next Thursday the most recent -rc will be selected as the base, and won't be changed until 12.05 is released. Most probably it will be v3.4-rc7. The 12.05 linux-linaro tree will get the ARM and Samsung LTs topics plus the 7 generic topics currently included into the linux-linaro-core-tracking tree: ufs (ufs-for-linux-linaro) emmc (emmc-for-linux-linaro) thermal_exynos4_imx6 (thermal_exynos4_imx6_work) linaro-android-3.4 armlt-gator (tracking-armlt-gator) umm-wip (umm-3.4rc4-wip) linaro-configs-3.4 If you don't see your generic topic in this list, but you think it should be there, please let me know ASAP. If you have a new topic to add, please send me the request before the next Thursday, May 17; the sooner, the better. The requirements for a topic can be found here: https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelTreeProcess#Adding_a_topic_to_linux-linaro_kernel_and_maintaining_it The landing teams - please update your topic branches if needed: ARM: tracking-armlt-hdlcd tracking-armlt-mmc tracking-armlt-arm-arch-fixes tracking-armlt-misc-fixes tracking-armlt-ubuntu-config tracking-armlt-android-config Samsung: topic/base topic/core topic/bl topic/dt topic/fb topic/pd topic/s2ram topic/asv_cpufreq topic/led topic/dummy_reg topic/gadget topic/touch topic/wlan topic/audio topic/hdmi topic/mali topic/cma_v24 topic/android_config Is any other LT using CMA patchset? If so, this topic branch can be moved into linux-linaro-core-tracking. That's a good idea, thanks! The only problem is that your topic/cma_v24 is based on the topic/base, and thus includes CONFIG: ORIGEN: commits and an older version of linaro-configs-3.4 topic. In particular, the latter recreates configs/panda.conf file which has been deleted from the current linaro-configs-3.4. Could you please make topic/cma_v24 mainline based (drop these CONFIG: ORIGEN: and configs/* changes)? And is the CONFIG_CMA_SIZE_MBYTES=32 option Origen specific or generic? If it is generic, it should go into a separate file, e.g. configs/cma.conf. I didn't mean to include topic/cma_v24 with the patches from topic/base, rather the clean patchset from Marek. But now that we have the umm topic branch in linux-linaro-core-tracking, we don't need topic/cma_v24 anymore. If any fixes with respect to Origen are required, I will queue them up in another topic branch. I will shortly send you the list of topic branches for 2012.05 release, now that 3.4-rc7 is already released. Thanks, Andrey -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 12.05 linux-linaro kernel tree
On 05/11/2012 01:04 AM, Andrey Konovalov wrote: Greetings, So far I wasn't updating the linux-linaro tree since the 12.04 release. (The generic topic updates were being done to the linux-linaro-core-tracking tree) Now it is time to move the focus to the linux-linaro tree. For one week it will use the mainline tip as the base. Then, on next Thursday the most recent -rc will be selected as the base, and won't be changed until 12.05 is released. Most probably it will be v3.4-rc7. The 12.05 linux-linaro tree will get the ARM and Samsung LTs topics plus the 7 generic topics currently included into the linux-linaro-core-tracking tree: ufs (ufs-for-linux-linaro) emmc (emmc-for-linux-linaro) thermal_exynos4_imx6 (thermal_exynos4_imx6_work) linaro-android-3.4 armlt-gator (tracking-armlt-gator) umm-wip (umm-3.4rc4-wip) linaro-configs-3.4 If you don't see your generic topic in this list, but you think it should be there, please let me know ASAP. If you have a new topic to add, please send me the request before the next Thursday, May 17; the sooner, the better. The requirements for a topic can be found here: https://wiki.linaro.org/Platform/DevPlatform/LinuxLinaroKernelTreeProcess#Adding_a_topic_to_linux-linaro_kernel_and_maintaining_it The landing teams - please update your topic branches if needed: ARM: tracking-armlt-hdlcd tracking-armlt-mmc tracking-armlt-arm-arch-fixes tracking-armlt-misc-fixes tracking-armlt-ubuntu-config tracking-armlt-android-config Samsung: topic/base topic/core topic/bl topic/dt topic/fb topic/pd topic/s2ram topic/asv_cpufreq topic/led topic/dummy_reg topic/gadget topic/touch topic/wlan topic/audio topic/hdmi topic/mali topic/cma_v24 topic/android_config Is any other LT using CMA patchset? If so, this topic branch can be moved into linux-linaro-core-tracking. Thanks, Andrey ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Preliminary 12.04 linux-linaro kernel tree
Hi Tixy, On 04/18/2012 01:24 PM, Jon Medhurst (Tixy) wrote: On Wed, 2012-04-18 at 02:16 +0400, Andrey Konovalov wrote: Greetings, I've pushed the current linux-linaro tree to git://git.linaro.org/kernel/linux-linaro-tracking.git , linux-linaro branch. This fails to build for vexpress because the Samsung Mali topic defaults to enabling Mali and UMP, they should probably default to being disabled and the Origen defconfig should enable them. After editing drivers/gpu/arm/mali/Kconfig to make config MALI400MP 'default n', and similar with config UMP in drivers/gpu/arm/ump/Kconfig then things build OK. The resulting kernel successfully booted an Oneiric desktop image I had from a couple of weeks ago. Ok ... I will update the same in Samsung Mali topic. -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Preliminary 12.04 linux-linaro kernel tree
Hi Tixy, On 04/18/2012 01:28 PM, Tushar Behera wrote: Hi Tixy, On 04/18/2012 01:24 PM, Jon Medhurst (Tixy) wrote: On Wed, 2012-04-18 at 02:16 +0400, Andrey Konovalov wrote: Greetings, I've pushed the current linux-linaro tree to git://git.linaro.org/kernel/linux-linaro-tracking.git , linux-linaro branch. This fails to build for vexpress because the Samsung Mali topic defaults to enabling Mali and UMP, they should probably default to being disabled and the Origen defconfig should enable them. After editing drivers/gpu/arm/mali/Kconfig to make config MALI400MP 'default n', and similar with config UMP in drivers/gpu/arm/ump/Kconfig then things build OK. The resulting kernel successfully booted an Oneiric desktop image I had from a couple of weeks ago. Ok ... I will update the same in Samsung Mali topic. I have update topic/mali here. [1] Can you please confirm if you wanted it that way? -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Thermal release for this month.
On 04/13/2012 07:22 PM, Amit Kucheria wrote: Adding Guodong and Tushar to make sure that the LT trees also have thermal management turned on for 12.04. In Samsung LT kernel, we have included thermal_v2 patchset from Amit. And cc'ing linaro-dev and the release manager. :) /Amit On Fri, Apr 13, 2012 at 4:47 PM, Amit Kachhap amit.kach...@linaro.org wrote: Hi Andrey, Please pull the thermal management work for exynos4 and imx6 platforms for this month release. As for merging various topic branches to linux-linaro-tracking, I would expect that the individual branches also enable relevant defconfig options. I don't see any better way to enable a specific feature in linux-linaro-tracking. git://git.linaro.org/people/amitdanielk/linux.git thermal_exynos4_imx6_work since commit id 258f742635360175564e9470eb060ff4d4b984e7 The necessary configs to be enabled are, https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/Kconfig#Thermal Thanks, Amit Daniel -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro 12.04 3.4-rc1 based androidization branch is available
On 04/13/2012 02:48 PM, Sangwook Lee wrote: Hi John On 11/04/12 20:19, John Stultz wrote: On 04/09/2012 03:18 PM, John Stultz wrote: I went ahead and forward ported the AOSP-3.3 tree to 3.4-rc1. You can grab it here: git://git.linaro.org/people/jstultz/android.git linaro-android-3.4-jstultz-rebase Sigh. Looks like the Google devs are following close behind and released their own 3.4-rc2 based tree. Don't get me wrong: Its great to see them keeping up with mainline, but I've clearly duplicated their work this cycle. I've gone ahead and mirrored the AOSP 3.4 tree here: git://git.linaro.org/people/jstultz/android.git linaro-android-3.4 Are you going to add merge_config.sh into this branch? merge_config.sh is in linaro-configs-3.4 on John's tree. The related patches have also been part of topic/base. Andrey: Probably you're call on this. If you've already merged in my rebase tree it should be fine for 12.04, but if not you might want to jump over to the AOSP 3.4 tree. thanks -john ___ 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 -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Linaro 12.04 3.4-rc1 based androidization branch is available
On 04/13/2012 04:19 PM, Tushar Behera wrote: On 04/13/2012 02:48 PM, Sangwook Lee wrote: Hi John On 11/04/12 20:19, John Stultz wrote: On 04/09/2012 03:18 PM, John Stultz wrote: I went ahead and forward ported the AOSP-3.3 tree to 3.4-rc1. You can grab it here: git://git.linaro.org/people/jstultz/android.git linaro-android-3.4-jstultz-rebase Sigh. Looks like the Google devs are following close behind and released their own 3.4-rc2 based tree. Don't get me wrong: Its great to see them keeping up with mainline, but I've clearly duplicated their work this cycle. I've gone ahead and mirrored the AOSP 3.4 tree here: git://git.linaro.org/people/jstultz/android.git linaro-android-3.4 Are you going to add merge_config.sh into this branch? merge_config.sh is in linaro-configs-3.4 on John's tree. The related patches have also been part of topic/base. I mean topic/base in Samsung's Landing team kernel. Andrey: Probably you're call on this. If you've already merged in my rebase tree it should be fine for 12.04, but if not you might want to jump over to the AOSP 3.4 tree. thanks -john ___ 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 -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Config fragment for Versatile Express
On 04/04/2012 01:02 PM, Jon Medhurst (Tixy) wrote: On Wed, 2012-04-04 at 10:05 +0530, Tushar Behera wrote: On 04/03/2012 03:59 PM, Jon Medhurst (Tixy) wrote: I think it makes sense if this 'upstream' doesn't include board files though, they should come from LT trees. As for the board specific fragments, I feel it would be better if the config-upstream tree has the initial fragment (which I suppose is minimal enough to compile the common kernel). That way anyone taking linux-linaro-tracking can have at least a working setup. I thought linux-linaro-tracking was going to operate a bit like linux-next, i.e. just a merge of all the topics from LTs and working groups, and from which Linaro produces it's releases and does some CI build+test. If that's true, then anyone using that tree will always have the LT code. In some cases, the mainline kernel cannot boot a specific board using the default config file. If we have a config fragment that adds the necessary changes, people can use that specific board even if LT has no other enablement patches merged to linux-linaro-tracking. An example would be the thermal patches, which got merged to linux-linaro-tracking through PM WG. But for someone to validate those changes, they won't have a definite config to build linux-linaro-tracking and run on Origen board. Hence I feel that having a minimal board fragment, that boots the kernel till console, in linux-linaro-samsung would be helpful. As long as we have same set of commits in our tree, we won't have merge conflicts too. Though I guess if LT code breaks other boards and has to get temporarily dropped, and if that LT code was pulled in as one monolithic topic like TI and Samsung trees, then it would probably mean dropping the board config too if we had that coming from the LT tree. But in that case, does it matter that the broken board can't be built from linux-linaro-tracking? That is one concern from my side too, as to how do we build linux-linaro-tracking kernel and what all things goes into that. -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Config fragment for Versatile Express
On 04/03/2012 01:43 PM, Jon Medhurst (Tixy) wrote: On Mon, 2012-04-02 at 12:30 -0700, John Stultz wrote: The difficulty is that as Tixy earlier pointed out, are that the LT kernel trees are mainline based, and thus aren't based off of something that would contain the base/distro/board config fragments. One approach we might be able to use is if the board defconfigs really are minimal, and restricted in scope to only the board options, we could switch the merge order (board/distro/base). This way the LT's additive defconfig can be used (from arch/arm/configs/ ) and we can still also get consistent generic options as well. The mainline defconfigs aren't minimal in the sense we want, they include things like file-systems and networking options so somebody can build a usable kernel, and I think it's sensible to keep it that way. For Linaro's purposes we would need a new board config. We could make that minimal, but we get back to the idea that topic branches which change configs would need to sit on top of the topic with this config. Perhaps that is something we can live with if a directory-of-config-fragments approach is deemed undesirable. It's a pity that the title of the thread possibly means no one from other LTs are reading. (Probably a bit late to change it now and get noticed.) I hope not. For Samsung LT kernel, we have followed an approach where in the commits in John's linaro_config_3.3 branch are taken to be stable commits and we have put those commits as the very first set of commits on LT kernel. Our LT kernel being a _serialized_ kernel where topic branches sit one over the other, the related config fragments are made part of the topic branches. A sample view of the same is posted at [1]. [1] git://git.linaro.org/landing-teams/working/samsung/kernel.git (lt/next) -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Config fragment for Versatile Express
On 04/03/2012 03:59 PM, Jon Medhurst (Tixy) wrote: On Tue, 2012-04-03 at 14:51 +0530, Tushar Behera wrote: For Samsung LT kernel, we have followed an approach where in the commits in John's linaro_config_3.3 branch are taken to be stable commits and we have put those commits as the very first set of commits on LT kernel. Our LT kernel being a _serialized_ kernel where topic branches sit one over the other, the related config fragments are made part of the topic branches. A sample view of the same is posted at [1]. [1] git://git.linaro.org/landing-teams/working/samsung/kernel.git (lt/next) The Samsung tree has the non samsung config files, like linaro-base.conf. I was wondering if that would cause merge problems if every LT had them and at possibly different versions. I guess it doesn't This method works well if the common config fragments, once committed to some upstream tree, are stable. Then only it makes sense to base other topics on top of this. matter so long as all LTs got them from the same definitive 'upstream' source, and that they didn't edit them. I think it makes sense if this 'upstream' doesn't include board files though, they should come from LT trees. As for the board specific fragments, I feel it would be better if the config-upstream tree has the initial fragment (which I suppose is minimal enough to compile the common kernel). That way anyone taking linux-linaro-tracking can have at least a working setup. As and when some topics get merged to mainline, we can move those config-fragments to upstream tree. We also need a better upstream than John's personal Android tree :-) I suppose, it would soon get a place in linux-linaro-tracking. -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] First pass config fragment breakout for linaro kernel
On 03/29/2012 11:25 PM, John Stultz wrote: On 03/28/2012 09:37 PM, Tushar Behera wrote: On 03/28/2012 10:17 PM, John Stultz wrote: On 03/28/2012 05:24 AM, Tushar Behera wrote: On 03/27/2012 12:50 AM, John Stultz wrote: So after talking about it at the last Linaro Connect, I've finally gotten around to making a first pass at providing config fragments for the linaro kernel. I'd like to propose merging this for 12.04, and doing so early so we can make sure that all the desired config options are present in the fragments and to allow the vairous linaro build systems to begin migrating their config generation over. The current tree is here: http://git.linaro.org/gitweb?p=people/jstultz/android.git;a=shortlog;h=refs/heads/linaro-configs-3.3 The most relevant commit being: http://git.linaro.org/gitweb?p=people/jstultz/android.git;a=commitdiff;h=da8f6d20e1a768cb486005c5ec62582b6f92990d This includes config fragments for a linaro-base, an android-ization fragment, and board configs for panda, origen and imx53. I suspect we'll need an ubuntu specific fragment as well as all the other board fragments. There is likely to be quite a bit of churn as we decide what sort of configs are really common and which are board specific. But that's ok. Configs are generated from the config fragments, as follows: ./scripts/kconfig/merge_config.sh ./configs/linaro-base.conf ./configs/android.conf ./configs/panda.conf You may see warnings, which are not fatal, but should be reported so they can be properly cleaned up. I'm asking for Build folks to take a look at the above and consider how they might merge in fragment assembly into their system replacing their current config generation. I'd ask Landing teams to take a look at this, and report any missing config options or fragment chunks they'd like to see. I have updated origen.conf and linaro-base.conf for testing Samsung LT kernel. The results are updated in [1]. I'll take a look at the changes and try to merge them into my tree. Ok. I've merged most of what you added, but made some tweaks of my own to quiet some of the warnings at merge time. Let me know if you see anything badly missing. Some of the items I dropped look like they're from feature branches? Right, some of the config options should better move to the feature branches. I have cleaned up origen.conf so that we can now boot linux-linaro-tracking kernel till the console. Code dropped at [1]. With the help of a couple of patches[2], I was able to get Ubuntu booting up till home screen. I haven't tested Android though. Following is the list of added patches. 0b066ba ARM: EXYNOS: Increase DMA pool allocator size for framebuffer This patch is not required if CMA patches are added to the kernel. fb8fa05 ARM: EXYNOS: Add clkdev lookup entry for lcd clock A rebased version of this patch is queued for 3.4-rc1. [1] git://git.linaro.org/landing-teams/working/samsung/kernel.git (topic/linaro_config_3.3) [2] git://git.linaro.org/landing-teams/working/samsung/kernel.git (test/linux-linaro-tracking) -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: Ubuntu LEB 12.03 RC images
On 03/29/2012 12:58 PM, Ricardo Salveti wrote: On Tue, Mar 27, 2012 at 10:37 AM, Ricardo Salveti ricardo.salv...@linaro.org wrote: Hi, A little bit later than usual, but here it goes the announcement of the 12.03 RC images. This time we got a bit delayed because we're finally generating and maintaining all the kernel packages ourself, and getting them in sync with Launchpad is something that still needs some improvement. This release should be the last one based on Ubuntu Oneiric (and ARMEL), including the latest XBMC release and the usual kernel and package updates. From 12.04 on we will be supporting only builds based on Ubuntu Precise (12.04, ARMHF), so we should see quite many nice improvements there (for early access, check the builds at https://ci.linaro.org/jenkins/view/Ubuntu%20Build%20Service/). You can find our current test cases at https://wiki.linaro.org/Platform/QA/TestCases/Ubuntu, and the 12.03 RC builds (for all boards and image flavors) at http://snapshots.linaro.org/oneiric/, with build id 20120327-1 for hwpacks and 20120327-0 for the rootfs (nano, developer, alip, ubuntu-desktop and linaro-tv-xbmc). For our main boards we also have a testing spreadsheet, were we publish the official release testing, done by the dev platform engineers. You can find the links at https://wiki.linaro.org/Platform/DevPlatform/Testing (note that you can find the bug reports from the test cases by looking at the QA page tag links). Fathi will be coordinating all respin requests in the next following days at linaro-release m-l, and the final image will be published this thursday, at releases.linaro.org. Ok, after a few rounds of testing, issues with ci.linaro.org and Launchpad, I'm finally able to publish the current status of the RC images, and the respin requests for tomorrow. RC Images that worked as expected, without needing extra fixes: - Ubuntu Desktop: http://snapshots.linaro.org/oneiric/linaro-o-ubuntu-desktop/20120327/0/images/tar/ - Nano: http://snapshots.linaro.org/oneiric/linaro-o-nano/20120327/1/images/tar/ (1 as 0 didn't build due archive instabilities) - Alip: http://snapshots.linaro.org/oneiric/linaro-o-alip/20120327/0/images/tar/ - Developer: http://snapshots.linaro.org/oneiric/linaro-o-developer/20120327/1/images/tar/ (1 as 0 didn't build due archive instabilities) RC Hwpacks that also worked as expected, without needing extra fixes: - 3.3 LT Snowball: http://snapshots.linaro.org/oneiric/lt-snowball-oneiric/20120327/1/images/hwpack - 3.3 LT Vexpress A9: http://snapshots.linaro.org/oneiric/lt-vexpress-a9-oneiric/20120327/1/images/hwpack - 3.3 Linux Linaro Pandaboard: http://snapshots.linaro.org/oneiric/lt-panda-oneiric/20120327/1/images/hwpack - 3.3 Linux Linaro Pandaboard X11 Base: http://snapshots.linaro.org/oneiric/lt-panda-x11-base-oneiric/20120327/1/images/hwpack RC Hwpacks that weren't tested yet: - 3.1 Linux Linaro EfikaMX: http://snapshots.linaro.org/oneiric/efikamx-oneiric/20120327/1/images/hwpack/ - 3.1 Linux Linaro iMX51: http://snapshots.linaro.org/oneiric/imx51-oneiric/20120327/1/images/hwpack/ - 3.1 LT MX5: http://snapshots.linaro.org/oneiric/lt-mx5-oneiric/20120327/1/images/hwpack/ - 3.3 Linux Linaro Igep: http://snapshots.linaro.org/oneiric/igep-oneiric/20120327/1/images/hwpack/ - 3.3 Linux Linaro Overo: http://snapshots.linaro.org/oneiric/overo-oneiric/20120327/1/images/hwpack/ RC Hwpacks currently broken without a solution yet: - 3.3 Linux Linaro Vexpress A9: http://snapshots.linaro.org/oneiric/vexpress-a9-oneiric/20120328/1/images/hwpack/ - 3.3 Linux Linaro Beagleboard (John Rigby is still debugging): http://snapshots.linaro.org/oneiric/omap3-oneiric/20120327/1/images/hwpack/ Respin request for images: - LinaroTV-XBMC: http://snapshots.linaro.org/oneiric/linaro-o-linarotv-xbmc/20120328/3/images/tar/ - Reason: Fixes at the XBMC package, update to the final 11 Eden release. Respin requests for hwpacks: - 3.2 LT MX6: http://snapshots.linaro.org/oneiric/lt-mx6-oneiric/20120329/1/images/hwpack/ - Reason: Fixes to improve the booting experience, but still not yet fixing it completely :-( - 3.1 LT Pandaboard: - http://snapshots.linaro.org/oneiric/lt-panda-oneiric/20120329/0/images/hwpack/ - http://snapshots.linaro.org/oneiric/lt-panda-x11-base-oneiric/20120329/0/images/hwpack/ - Reason: Kernel updates, config updates and working hw video decoding again. Thanks, Status of Origen is missing in the list :( -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] First pass config fragment breakout for linaro kernel
On 03/29/2012 10:50 PM, John Stultz wrote: On 03/28/2012 09:37 PM, Tushar Behera wrote: On 03/28/2012 10:17 PM, John Stultz wrote: On 03/28/2012 05:24 AM, Tushar Behera wrote: I have not validated the changes in android.conf, but by merging linaro-base.conf and origen.conf, I was able to boot my kernel the way I would have expected when using exynos4_defconfig. One thing I notice is that I find far too many debug messages with this new config. You mean the debug output from the merge_config.sh script is a bit noisy? Yea. Likely we'll have some extra noise as we settle out what options needs to be generic vs board specific. But it should decrease over time. I was talking about the console log messages upon booting on a target board. Ok. Can you send me a Before config where you didn't see all the log messages? The new log messages are because of this config entry. CONFIG_PROVE_LOCKING=y But the information is useful, hence better it stays that way. thanks -john ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] First pass config fragment breakout for linaro kernel
On 03/27/2012 12:50 AM, John Stultz wrote: So after talking about it at the last Linaro Connect, I've finally gotten around to making a first pass at providing config fragments for the linaro kernel. I'd like to propose merging this for 12.04, and doing so early so we can make sure that all the desired config options are present in the fragments and to allow the vairous linaro build systems to begin migrating their config generation over. The current tree is here: http://git.linaro.org/gitweb?p=people/jstultz/android.git;a=shortlog;h=refs/heads/linaro-configs-3.3 The most relevant commit being: http://git.linaro.org/gitweb?p=people/jstultz/android.git;a=commitdiff;h=da8f6d20e1a768cb486005c5ec62582b6f92990d This includes config fragments for a linaro-base, an android-ization fragment, and board configs for panda, origen and imx53. I suspect we'll need an ubuntu specific fragment as well as all the other board fragments. There is likely to be quite a bit of churn as we decide what sort of configs are really common and which are board specific. But that's ok. Configs are generated from the config fragments, as follows: ./scripts/kconfig/merge_config.sh ./configs/linaro-base.conf ./configs/android.conf ./configs/panda.conf You may see warnings, which are not fatal, but should be reported so they can be properly cleaned up. I'm asking for Build folks to take a look at the above and consider how they might merge in fragment assembly into their system replacing their current config generation. I'd ask Landing teams to take a look at this, and report any missing config options or fragment chunks they'd like to see. I have updated origen.conf and linaro-base.conf for testing Samsung LT kernel. The results are updated in [1]. I have not validated the changes in android.conf, but by merging linaro-base.conf and origen.conf, I was able to boot my kernel the way I would have expected when using exynos4_defconfig. One thing I notice is that I find far too many debug messages with this new config. Going forward, would it be better to have linaro-base.conf, android.conf and ubuntu.conf managed centrally and each LT managing their board specific configuration file. That way, we can include the changes in our board specific configurations in respective topic branches. [1] git://git.linaro.org/landing-teams/working/samsung/kernel.git (lt/linaro_config_3.3-g2d) thanks -john ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [RFC] First pass config fragment breakout for linaro kernel
On 03/28/2012 10:17 PM, John Stultz wrote: On 03/28/2012 05:24 AM, Tushar Behera wrote: On 03/27/2012 12:50 AM, John Stultz wrote: So after talking about it at the last Linaro Connect, I've finally gotten around to making a first pass at providing config fragments for the linaro kernel. I'd like to propose merging this for 12.04, and doing so early so we can make sure that all the desired config options are present in the fragments and to allow the vairous linaro build systems to begin migrating their config generation over. The current tree is here: http://git.linaro.org/gitweb?p=people/jstultz/android.git;a=shortlog;h=refs/heads/linaro-configs-3.3 The most relevant commit being: http://git.linaro.org/gitweb?p=people/jstultz/android.git;a=commitdiff;h=da8f6d20e1a768cb486005c5ec62582b6f92990d This includes config fragments for a linaro-base, an android-ization fragment, and board configs for panda, origen and imx53. I suspect we'll need an ubuntu specific fragment as well as all the other board fragments. There is likely to be quite a bit of churn as we decide what sort of configs are really common and which are board specific. But that's ok. Configs are generated from the config fragments, as follows: ./scripts/kconfig/merge_config.sh ./configs/linaro-base.conf ./configs/android.conf ./configs/panda.conf You may see warnings, which are not fatal, but should be reported so they can be properly cleaned up. I'm asking for Build folks to take a look at the above and consider how they might merge in fragment assembly into their system replacing their current config generation. I'd ask Landing teams to take a look at this, and report any missing config options or fragment chunks they'd like to see. I have updated origen.conf and linaro-base.conf for testing Samsung LT kernel. The results are updated in [1]. I'll take a look at the changes and try to merge them into my tree. I have not validated the changes in android.conf, but by merging linaro-base.conf and origen.conf, I was able to boot my kernel the way I would have expected when using exynos4_defconfig. One thing I notice is that I find far too many debug messages with this new config. You mean the debug output from the merge_config.sh script is a bit noisy? Yea. Likely we'll have some extra noise as we settle out what options needs to be generic vs board specific. But it should decrease over time. I was talking about the console log messages upon booting on a target board. Going forward, would it be better to have linaro-base.conf, android.conf and ubuntu.conf managed centrally and each LT managing their board specific configuration file. That way, we can include the changes in our board specific configurations in respective topic branches. So yea, I'd like to delegate/give away as much management of the configs as possible. :) That said, I do think that we'll need someone looking at the entire cross-board fragment picture (since if everyone needs an option, it really isn't board specific). So it might be a good idea to have basic board config fragments that work with upstream. Then any board-specific feature branches can add their config needs in as a patch on top. Does that sound reasonable? Sounds good. Any config that enables a feature on a topic branch specific to a board should go in a patch in the topic branch itself. -- Tushar Behera ___ 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 03/16/2012 05:20 PM, Mans Rullgard wrote: On 16 March 2012 04:14, Sachin Kamat sachin.ka...@linaro.org wrote: 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) That branch still needs one more patch (attached). Thanks Mans for the patch. I have applied it to our tree. [1] I would be nice if you can test this kernel once. [1] git://git.linaro.org/landing-teams/working/samsung/kernel.git (tracking) ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [Samsung] [U-Boot] [PATCH] EXYNOS: Rename exynos5_tzpc structure to s5p_tzpc
On 03/15/2012 06:53 AM, Minkyu Kang wrote:
Dear Chander Kashyap,
On 14 March 2012 22:38, Chander Kashyap chander.kash...@linaro.org wrote:
Hi Kyungmin Park,
On 14 March 2012 19:02, Kyungmin Park kmp...@infradead.org wrote:
Hi Chander,
On Wed, Mar 14, 2012 at 10:14 PM, Chander Kashyap
chander.kash...@linaro.org wrote:
TZPC IP is common across S5P and Exynos based SoC'c. Renaming exynos5_tzpc
in arch/arm/include/asm/arch-exynos/tzpc.h to s5p_tzpc will allow generic
usase of tzpc.
Also modify board/samsung/smdk5250/tzpc_init.c to use s5p_tzpc.
Signed-off-by: Chander Kashyap chander.kash...@linaro.org
---
arch/arm/include/asm/arch-exynos/tzpc.h |2 +-
board/samsung/smdk5250/tzpc_init.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/arch-exynos/tzpc.h
b/arch/arm/include/asm/arch-exynos/tzpc.h
index 2c9a07b..63736ae 100644
--- a/arch/arm/include/asm/arch-exynos/tzpc.h
+++ b/arch/arm/include/asm/arch-exynos/tzpc.h
@@ -22,7 +22,7 @@
#define __TZPC_H_
#ifndef __ASSEMBLY__
-struct exynos5_tzpc {
+struct s5p_tzpc {
I think 'exynos' is preferable. Even though each SOC has different
I tried to carry forward old conventions as in case of watchdog. I
will change it to exynos.
I agreed with Kyungmin.
From now, let's called exynos for common name including s5pc1xx and
s5pc2xx and exynos4 and exynos5.. etc.
From the above list, only s5pc1xx series was not named EXYNOS.
number of tzpc. It can be covered one exynos_tzpc. or we can define
it for each SoC.
One structure is enough as fields are same.
Thanks
Minkyu Kang.
--
Tushar Behera
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 2/3] ARM: EXYNOS: Add clkdev lookup entry for lcd clock
On 03/10/2012 07:52 PM, Chenglie He wrote:
I am doing the suspend and resume of s3cfb on exynos. the clk_on and
clk_off just failed. I think this is a related issue.
Without this patch, the probe for s3cfb driver itself fails - hence what
you are seeing must be different.
On 29 February 2012 13:45, Tushar Behera tushar.beh...@linaro.org wrote:
Hi Kukjin,
On 12/01/2011 11:20 AM, Tushar Behera wrote:
The framebuffer driver needs the clock named 'lcd' as its bus
clock but the equivalent clock on Exynos4 is named as 'fimd'.
Hence, create a clkdev lookup entry with the name 'lcd' that
references the 'fimd' clock.
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
arch/arm/mach-exynos/clock.c | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-exynos/clock.c b/arch/arm/mach-exynos/clock.c
index 5d8d483..607ec28 100644
--- a/arch/arm/mach-exynos/clock.c
+++ b/arch/arm/mach-exynos/clock.c
@@ -489,11 +489,6 @@ static struct clk init_clocks_off[] = {
.enable = exynos4_clk_ip_cam_ctrl,
.ctrlbit= (1 3),
}, {
- .name = fimd,
- .devname= exynos4-fb.0,
- .enable = exynos4_clk_ip_lcd0_ctrl,
- .ctrlbit= (1 0),
- }, {
.name = hsmmc,
.devname= s3c-sdhci.0,
.parent = clk_aclk_133.clk,
@@ -782,6 +777,13 @@ static struct clk clk_pdma1 = {
.ctrlbit= (1 1),
};
+static struct clk clk_fimd0 = {
+ .name = fimd,
+ .devname= exynos4-fb.0,
+ .enable = exynos4_clk_ip_lcd0_ctrl,
+ .ctrlbit= (1 0),
+};
+
struct clk *clkset_group_list[] = {
[0] = clk_ext_xtal_mux,
[1] = clk_xusbxti,
@@ -1294,6 +1296,7 @@ static struct clksrc_clk *sysclks[] = {
static struct clk *clk_cdev[] = {
clk_pdma0,
clk_pdma1,
+ clk_fimd0,
};
static struct clksrc_clk *clksrc_cdev[] = {
@@ -1318,6 +1321,7 @@ static struct clk_lookup exynos4_clk_lookup[] = {
CLKDEV_INIT(s3c-sdhci.3, mmc_busclk.2, clk_sclk_mmc3.clk),
CLKDEV_INIT(dma-pl330.0, apb_pclk, clk_pdma0),
CLKDEV_INIT(dma-pl330.1, apb_pclk, clk_pdma1),
+ CLKDEV_INIT(exynos4-fb.0, lcd, clk_fimd0),
};
static int xtal_rate;
Would you please review this patch and let me know your opinion? Without
this patch, frame-buffer support on EXYNOS4 is broken.
--
Tushar Behera
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
--
Tushar Behera
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 1/4] thermal: exynos: Add thermal interface support for linux thermal layer
;
+ goto err_unregister;
+ }
+
+ th_zone-sensor_conf = sensor_conf;
+
+ tab_ptr = (struct freq_pctg_table *)sensor_conf-cooling_data.freq_data;
+ tab_size = sensor_conf-cooling_data.freq_pctg_count;
+
+ /*Register the cpufreq cooling device*/
Space after '/*' and before '*/'.
+ th_zone-cool_dev_size = 1;
+ count = 0;
+ th_zone-cool_dev[count] = cpufreq_cooling_register(
+ (struct freq_pctg_table *)(tab_ptr[count]),
+ tab_size, cpumask_of(0));
+
+ if (IS_ERR(th_zone-cool_dev[count])) {
+ pr_err(Failed to register cpufreq cooling device\n);
+ ret = -EINVAL;
+ th_zone-cool_dev_size = 0;
+ goto err_unregister;
+ }
+
+ th_zone-therm_dev = thermal_zone_device_register(sensor_conf-name,
+ 3, NULL, exynos4_dev_ops, 0, 0, 0, 1000);
+ if (IS_ERR(th_zone-therm_dev)) {
+ pr_err(Failed to register thermal zone device\n);
+ ret = -EINVAL;
+ goto err_unregister;
+ }
+
+ th_zone-active_interval = 1;
+ th_zone-idle_interval = 10;
+
+ exynos4_set_mode(th_zone-therm_dev, THERMAL_DEVICE_DISABLED);
+
+ pr_info(Exynos: Kernel Thermal management registered\n);
+
+ return 0;
+
+err_unregister:
+ exynos4_unregister_thermal();
+ return ret;
+}
+EXPORT_SYMBOL(exynos4_register_thermal);
+
+void exynos4_unregister_thermal(void)
+{
+ unsigned int i;
+
+ for (i = 0; i th_zone-cool_dev_size; i++) {
+ if (th_zone th_zone-cool_dev[i])
+ cpufreq_cooling_unregister(th_zone-cool_dev[i]);
+ }
+
+ if (th_zone th_zone-therm_dev)
+ thermal_zone_device_unregister(th_zone-therm_dev);
+
+ kfree(th_zone);
+
+ pr_info(Exynos: Kernel Thermal management unregistered\n);
+}
+EXPORT_SYMBOL(exynos4_unregister_thermal);
diff --git a/include/linux/exynos_thermal.h b/include/linux/exynos_thermal.h
new file mode 100644
index 000..186e409
--- /dev/null
+++ b/include/linux/exynos_thermal.h
@@ -0,0 +1,72 @@
+/* linux/include/linux/exynos_thermal.h
+ *
+ * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+*/
+
+#ifndef THERMAL_INTERFACE_H
+#define THERMAL_INTERFACE_H
+/* CPU Zone information */
+
+#define SENSOR_NAME_LEN 16
+#define MAX_TRIP_COUNT 8
+
+#define PANIC_ZONE 4
+#define WARN_ZONE 3
+#define MONITOR_ZONE2
+#define SAFE_ZONE 1
+#define NO_ACTION 0
+
TABs for intending in above defines.
+
+struct thermal_trip_point_conf {
A single space after struct should suffice, no TABs there. It is helpful
when we grep for the definition of 'struct thermal_trip_point_conf {'.
+ int trip_val[MAX_TRIP_COUNT];
+ int trip_count;
+};
+
+struct thermal_cooling_conf {
Ditto.
+ struct freq_pctg_table freq_data[MAX_TRIP_COUNT];
+ int freq_pctg_count;
+};
+
+/**
+ * struct exynos4_tmu_platform_data
+ * @name: name of the temperature sensor
+ * @read_temperature: A function pointer to read temperature info
+ * @private_data: Temperature sensor private data
+ * @sensor_data: Sensor specific information like trigger temperature, level
+ */
+struct thermal_sensor_conf {
+ charname[SENSOR_NAME_LEN];
+ int (*read_temperature)(void *data);
+ struct thermal_trip_point_conf trip_data;
+ struct thermal_cooling_conf cooling_data;
+ void*private_data;
+};
+
+/**
+ * exynos4_register_thermal: Register to the exynos thermal interface.
+ * @sensor_conf: Structure containing temperature sensor information
+ *
+ * returns zero on success, else negative errno.
+ */
+int exynos4_register_thermal(struct thermal_sensor_conf *sensor_conf);
+
+/**
+ * exynos4_unregister_thermal: Un-register from the exynos thermal interface.
+ *
+ * return not applicable.
+ */
+void exynos4_unregister_thermal(void);
+
+/**
+ * exynos4_report_trigger: Report any trigger level crossed in the
+ * temperature sensor. This may be useful to take any cooling action.
+ *
+ * return not applicable.
+ */
+extern void exynos4_report_trigger(void);
+#endif
--
Tushar Behera
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 1/2] ARM: EXYNOS: Add EHCI AHB burst function
On 02/29/2012 06:31 PM, Thomas Abraham wrote:
Hi Sangwook,
On 29 February 2012 18:11, Sangwook Lee sangwook@linaro.org wrote:
Enable burst transfer from AHB for EHCI.
This fixes data transfer of USB Ethernet with EHCI.
Without this patch, scp hardly works.
Signed-off-by: Sangwook Lee sangwook@linaro.org
---
arch/arm/mach-exynos/setup-usb-phy.c |6 ++
arch/arm/plat-samsung/devs.c |2 ++
arch/arm/plat-samsung/include/plat/ehci.h | 19 +++
3 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos/setup-usb-phy.c
b/arch/arm/mach-exynos/setup-usb-phy.c
index 41743d2..5a20460 100644
--- a/arch/arm/mach-exynos/setup-usb-phy.c
+++ b/arch/arm/mach-exynos/setup-usb-phy.c
@@ -18,6 +18,7 @@
#include mach/regs-usb-phy.h
#include plat/cpu.h
#include plat/usb-phy.h
+#include plat/ehci.h
static atomic_t host_usage;
@@ -149,3 +150,8 @@ int s5p_usb_phy_exit(struct platform_device *pdev, int
type)
return -EINVAL;
}
+
+void s5p_ehci_burst_enable(struct platform_device *pdev, void __iomem *base)
+{
+ writel(EHCI_INSNREG00_ENABLE_BURST, base + EHCI_INSNREG00);
+}
This functionality can be added in ehci-s5p itself and avoid adding a
new platform callback in platform data. If this is specific to exynos,
driver data could be added in ehci-s5p to indicate platforms that need
this to be enabled.
Am I right in assuming that ehci-s5p driver can also be used for
mach-s5pv210?
The related bit-fields are reserved in S5PV210. So, won't it cause any
side-effects?
Thanks,
Thomas.
[...]
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Tushar Behera
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 1/2] ARM: EXYNOS: Add USB HOST register definitions
On 02/29/2012 08:09 PM, Jingoo Han wrote: This patch adds USB HOST register definitions. The definition for EHCI INSNREG00 regiser and corresponding bit field definitions are added. Signed-off-by: Jingoo Han jg1@samsung.com --- arch/arm/mach-exynos/include/mach/regs-usb-host.h | 23 + 1 files changed, 23 insertions(+), 0 deletions(-) create mode 100644 arch/arm/mach-exynos/include/mach/regs-usb-host.h diff --git a/arch/arm/mach-exynos/include/mach/regs-usb-host.h b/arch/arm/mach-exynos/include/mach/regs-usb-host.h new file mode 100644 index 000..1a60f27 --- /dev/null +++ b/arch/arm/mach-exynos/include/mach/regs-usb-host.h @@ -0,0 +1,23 @@ +/* + * Copyright (C) 2012 Samsung Electronics Co.Ltd + * http://www.samsung.com + * + * EXYNOS - USB HOST register definitions + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#ifndef __REGS_USB_HOST_H +#define __REGS_USB_HOST_H __FILE__ + +#define EHCI_INSNREG00(base) (base + 0x90) +#define EHCI_ENA_INCR16 (0x1 25) +#define EHCI_ENA_INCR8 (0x1 24) +#define EHCI_ENA_INCR4 (0x1 23) +#define EHCI_ENA_INCRX_ALIGN (0x1 22) +#define EHCI_ENABLE_DMA_INCR (EHCI_ENA_INCR16 | EHCI_ENA_INCR8| \ + EHCI_ENA_INCR4 | EHCI_ENA_INCRX_ALIGN) + As per the definition of bit-fields in other registers, it would be good to prepend the complete register name before the bit-field defines. EHCI_INSNREG00_ENA_INCR16 ... Considering the similarity of this patchset with the earlier patchset from Sangwook, IMO, it would be appropriate to give him due credit in both these patches. +#endif /* __REGS_USB_HOST_H */ -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 2/3] ARM: EXYNOS: Add clkdev lookup entry for lcd clock
Hi Kukjin, On 03/01/2012 09:36 AM, Kukjin Kim wrote: Jingoo Han wrote: Hi Tushar, (please don't top-post) -Original Message- From: linux-samsung-soc-ow...@vger.kernel.org [mailto:linux-samsung-soc- ow...@vger.kernel.org] On Behalf Of Tushar Behera Sent: Thursday, December 01, 2011 2:50 PM To: linux-samsung-...@vger.kernel.org Cc: kgene@samsung.com; linaro-dev@lists.linaro.org; patc...@linaro.org Subject: [PATCH 2/3] ARM: EXYNOS: Add clkdev lookup entry for lcd clock The framebuffer driver needs the clock named 'lcd' as its bus clock but the equivalent clock on Exynos4 is named as 'fimd'. Hence, create a clkdev lookup entry with the name 'lcd' that references the 'fimd' clock. Signed-off-by: Tushar Behera tushar.beh...@linaro.org Acked-by: Jingoo Han jg1@samsung.com OK, I will apply this with Sylwester's 'reviewed-by' I looked at before. Thanks. Do you want me rebase this patch on your latest for-next and resend? BTW, Tushar, what's the [1/3] and [3/3] in this series? If they are still needed now, could you please re-send? Maybe I missed. [PATCH 1/3] ARM: EXYNOS: Increase DMA pool allocator size for framebuffer - It should be dropped. [PATCH 3/3] ARM: EXYNOS: Invert VCLK polarity for framebuffer on Origen board - It has already been applied. Thanks. Best regards, Kgene. -- Kukjin Kim kgene@samsung.com, Senior Engineer, SW Solution Development Team, Samsung Electronics Co., Ltd. -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 2/3] ARM: EXYNOS: Add clkdev lookup entry for lcd clock
Hi Kukjin,
On 12/01/2011 11:20 AM, Tushar Behera wrote:
The framebuffer driver needs the clock named 'lcd' as its bus
clock but the equivalent clock on Exynos4 is named as 'fimd'.
Hence, create a clkdev lookup entry with the name 'lcd' that
references the 'fimd' clock.
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
arch/arm/mach-exynos/clock.c | 14 +-
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-exynos/clock.c b/arch/arm/mach-exynos/clock.c
index 5d8d483..607ec28 100644
--- a/arch/arm/mach-exynos/clock.c
+++ b/arch/arm/mach-exynos/clock.c
@@ -489,11 +489,6 @@ static struct clk init_clocks_off[] = {
.enable = exynos4_clk_ip_cam_ctrl,
.ctrlbit= (1 3),
}, {
- .name = fimd,
- .devname= exynos4-fb.0,
- .enable = exynos4_clk_ip_lcd0_ctrl,
- .ctrlbit= (1 0),
- }, {
.name = hsmmc,
.devname= s3c-sdhci.0,
.parent = clk_aclk_133.clk,
@@ -782,6 +777,13 @@ static struct clk clk_pdma1 = {
.ctrlbit= (1 1),
};
+static struct clk clk_fimd0 = {
+ .name = fimd,
+ .devname= exynos4-fb.0,
+ .enable = exynos4_clk_ip_lcd0_ctrl,
+ .ctrlbit= (1 0),
+};
+
struct clk *clkset_group_list[] = {
[0] = clk_ext_xtal_mux,
[1] = clk_xusbxti,
@@ -1294,6 +1296,7 @@ static struct clksrc_clk *sysclks[] = {
static struct clk *clk_cdev[] = {
clk_pdma0,
clk_pdma1,
+ clk_fimd0,
};
static struct clksrc_clk *clksrc_cdev[] = {
@@ -1318,6 +1321,7 @@ static struct clk_lookup exynos4_clk_lookup[] = {
CLKDEV_INIT(s3c-sdhci.3, mmc_busclk.2, clk_sclk_mmc3.clk),
CLKDEV_INIT(dma-pl330.0, apb_pclk, clk_pdma0),
CLKDEV_INIT(dma-pl330.1, apb_pclk, clk_pdma1),
+ CLKDEV_INIT(exynos4-fb.0, lcd, clk_fimd0),
};
static int xtal_rate;
Would you please review this patch and let me know your opinion? Without
this patch, frame-buffer support on EXYNOS4 is broken.
--
Tushar Behera
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Selecting default framebuffer through kernel command-line ?
Hi, This issue is currently specific to the Ubuntu LEB for Origen and is also being discussed under the LP bug #906762 [1]. Writing to a wider audience to get views of others who might have come across similar situation before. Currently the LCD FB is registered as /dev/fb0 and the HDMI FB is registered as /dev/fb1. While booting up, by default /dev/fb0 is used as the primary display device and the output is routed accordingly. To use the HDMI display, we need to update /etc/X11/xorg.conf (and this needs to be updated every time we update the file-system.) If we don't enable support for LCD FB, the display comes on HDMI during boot-time, but again that is not desirable considering we want to use both the LCD and HDMI with the same kernel binary. Is there any way where we can force the default frame-buffer (whether to choose /dev/fb0 or /dev/fb1) during boot-time, might be through some kernel command-line options? [1] https://bugs.launchpad.net/linaro-landing-team-samsung/+bug/906762 -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: 2012-01 Samsung kernel trees
Hi Vic, CC: sams...@lists.linaro.org On 01/30/2012 08:54 AM, Vic Berdin wrote: Hi everyone, Any chance the linux-linaro-*-lt-samsung kernel trees will get updated Samsung LT maintains following tree [1], you may have a look at it. Is that what you are looking for? (soon)? By the way, is there a daily/nightly build source for these trees? I am eager to try them out. The daily hwpacks can be found at [2]. [1] git://git.linaro.org/landing-teams/working/samsung/kernel.git (tracking) [2] http://snapshots.linaro.org/oneiric/lt-origen-oneiric/latest/ TIA - Vic ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH] ARM: EXYNOS: Add USB OHCI support to ORIGEN board
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
Signed-off-by: Angus Ainslie angus.ains...@linaro.org
---
This patch are based Kukjin's for-next branch and OHCI related
patches from Jingoo Han.
[PATCH v2 0/3] Support Samsung Exynos OHCI device and driver
arch/arm/mach-exynos/Kconfig |1 +
arch/arm/mach-exynos/mach-origen.c | 13 +
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index bd1bb9f1..0da2ced 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -304,6 +304,7 @@ config MACH_ORIGEN
select SAMSUNG_DEV_PWM
select EXYNOS4_DEV_DMA
select EXYNOS4_DEV_PD
+ select EXYNOS4_DEV_USB_OHCI
select EXYNOS4_SETUP_FIMD0
select EXYNOS4_SETUP_SDHCI
select EXYNOS4_SETUP_USB_PHY
diff --git a/arch/arm/mach-exynos/mach-origen.c
b/arch/arm/mach-exynos/mach-origen.c
index f56d027..a0116036 100644
--- a/arch/arm/mach-exynos/mach-origen.c
+++ b/arch/arm/mach-exynos/mach-origen.c
@@ -42,6 +42,7 @@
#include plat/fb.h
#include plat/mfc.h
+#include mach/ohci.h
#include mach/map.h
/* Following are default values for UCON, ULCON and UFCON UART registers */
@@ -487,6 +488,16 @@ static void __init origen_ehci_init(void)
s5p_ehci_set_platdata(pdata);
}
+/* USB OHCI */
+static struct exynos4_ohci_platdata origen_ohci_pdata;
+
+static void __init origen_ohci_init(void)
+{
+ struct exynos4_ohci_platdata *pdata = origen_ohci_pdata;
+
+ exynos4_ohci_set_platdata(pdata);
+}
+
static struct gpio_keys_button origen_gpio_keys_table[] = {
{
.code = KEY_MENU,
@@ -627,6 +638,7 @@ static struct platform_device *origen_devices[] __initdata
= {
s5p_device_mfc_l,
s5p_device_mfc_r,
s5p_device_mixer,
+ exynos4_device_ohci,
exynos4_device_pd[PD_LCD0],
exynos4_device_pd[PD_TV],
exynos4_device_pd[PD_G3D],
@@ -702,6 +714,7 @@ static void __init origen_machine_init(void)
s3c_sdhci0_set_platdata(origen_hsmmc0_pdata);
origen_ehci_init();
+ origen_ohci_init();
clk_xusbxti.rate = 2400;
s5p_tv_setup();
--
1.7.4.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] i2c-s3c2410: Fix return code of s3c24xx_i2c_parse_dt_gpio
Ping
On 12/09/2011 03:33 PM, Tushar Behera wrote:
s3c24xx_i2c_parse_dt_gpio is called when cfg_gpio is not defined
in the platform data of the i2c device. When DT is not enabled,
the above function always returns -EINVAL. Since there can be
some i2c devices which don't need to configure any gpio lines,
the probe of such devices would fail here. Changing the default
return value to success would fix this issue.
Signed-off-by: Tushar Beheratushar.beh...@linaro.org
---
This patch is rebased on Kukjin's for-next branch.
d3d936c Merge branch 'samsung-fixes-2' into for-next
drivers/i2c/busses/i2c-s3c2410.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index 2754cef..b5caa42 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -786,7 +786,7 @@ static void s3c24xx_i2c_dt_gpio_free(struct s3c24xx_i2c
*i2c)
#else
static int s3c24xx_i2c_parse_dt_gpio(struct s3c24xx_i2c *i2c)
{
- return -EINVAL;
+ return 0;
}
static void s3c24xx_i2c_dt_gpio_free(struct s3c24xx_i2c *i2c)
--
Tushar Behera
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH] i2c-s3c2410: Fix return code of s3c24xx_i2c_parse_dt_gpio
s3c24xx_i2c_parse_dt_gpio is called when cfg_gpio is not defined
in the platform data of the i2c device. When DT is not enabled,
the above function always returns -EINVAL. Since there can be
some i2c devices which don't need to configure any gpio lines,
the probe of such devices would fail here. Changing the default
return value to success would fix this issue.
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
This patch is rebased on Kukjin's for-next branch.
d3d936c Merge branch 'samsung-fixes-2' into for-next
drivers/i2c/busses/i2c-s3c2410.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index 2754cef..b5caa42 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -786,7 +786,7 @@ static void s3c24xx_i2c_dt_gpio_free(struct s3c24xx_i2c
*i2c)
#else
static int s3c24xx_i2c_parse_dt_gpio(struct s3c24xx_i2c *i2c)
{
- return -EINVAL;
+ return 0;
}
static void s3c24xx_i2c_dt_gpio_free(struct s3c24xx_i2c *i2c)
--
1.7.4.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 0/2] Add PM_RUNTIME related fixes for PL330
Hi, When PM_RUNTIME is enabled, PL330 probe fails because of some mismatch in pm_runtime calls. This patchset fixes those issues. This patch is based on Kukjin's for-next branch and tested on EXYNOS4 based Origen board. d3d936c Merge branch 'samsung-fixes-2' into for-next Tushar Behera (2): To Vinod Koul vinod.k...@intel.com: DMA: PL330: Remove pm_runtime_xxx calls from pl330 probe/remove To Kukjin Kim kgene@samsung.com: ARM: EXYNOS: Add apb_pclk clkdev entry for mdma1 arch/arm/mach-exynos/clock.c |1 + drivers/dma/pl330.c | 17 ++--- 2 files changed, 3 insertions(+), 15 deletions(-) -- 1.7.4.1 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 1/2] DMA: PL330: Remove pm_runtime_xxx calls from pl330 probe/remove
amba_probe() now calls pm_runtime_get_noresume() and pm_runtime_enable()
for the devices before the device probe is called. Hence we don't need
to call pm_runtime_get_xxx and pm_runtime_enable() in device probe again.
In the same way, since amba_remove() calls the respective pm_runtime
functions, those functions need not be called from device remove.
This patch fixes following run time error with pl330 driver.
dma-pl330 dma-pl330.0: Unbalanced pm_runtime_enable!
dma-pl330 dma-pl330.0: failed to get runtime pm
Signed-off-by: Giridhar Maruthy giridhar.maru...@linaro.org
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
drivers/dma/pl330.c | 17 ++---
1 files changed, 2 insertions(+), 15 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index a626e15..cd07121 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -834,17 +834,7 @@ pl330_probe(struct amba_device *adev, const struct amba_id
*id)
amba_set_drvdata(adev, pdmac);
-#ifdef CONFIG_PM_RUNTIME
- /* to use the runtime PM helper functions */
- pm_runtime_enable(adev-dev);
-
- /* enable the power domain */
- if (pm_runtime_get_sync(adev-dev)) {
- dev_err(adev-dev, failed to get runtime pm\n);
- ret = -ENODEV;
- goto probe_err1;
- }
-#else
+#ifndef CONFIG_PM_RUNTIME
/* enable dma clk */
clk_enable(pdmac-clk);
#endif
@@ -977,10 +967,7 @@ static int __devexit pl330_remove(struct amba_device *adev)
res = adev-res;
release_mem_region(res-start, resource_size(res));
-#ifdef CONFIG_PM_RUNTIME
- pm_runtime_put(adev-dev);
- pm_runtime_disable(adev-dev);
-#else
+#ifndef CONFIG_PM_RUNTIME
clk_disable(pdmac-clk);
#endif
--
1.7.4.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 2/2] ARM: EXYNOS: Add apb_pclk clkdev entry for mdma1
Amba core assumes the pclk to be named as apb_pclk. During device probe,
it tries to get that clock and enable that. When PM_RUNTIME is enabled,
dma clock is not explicitly enabled in pl330_probe, which causes device
probe to fail. Adding a clkdev entry for apb_pclk for mdma1 fixes the
problem.
This patch fixes following runtime error.
dma-pl330 dma-pl330.2: PERIPH_ID 0x0, PCELL_ID 0x0 !
dma-pl330: probe of dma-pl330.2 failed with error -22
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
arch/arm/mach-exynos/clock.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos/clock.c b/arch/arm/mach-exynos/clock.c
index 28e2842..eb33a7a 100644
--- a/arch/arm/mach-exynos/clock.c
+++ b/arch/arm/mach-exynos/clock.c
@@ -1326,6 +1326,7 @@ static struct clk_lookup exynos4_clk_lookup[] = {
CLKDEV_INIT(s3c-sdhci.3, mmc_busclk.2, clk_sclk_mmc3.clk),
CLKDEV_INIT(dma-pl330.0, apb_pclk, clk_pdma0),
CLKDEV_INIT(dma-pl330.1, apb_pclk, clk_pdma1),
+ CLKDEV_INIT(dma-pl330.2, apb_pclk, clk_mdma1),
};
static int xtal_rate;
--
1.7.4.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: error while running l-m-c on one build machine
Hi Fathi, On Friday 14 October 2011 11:45 AM, Fathi Boudra wrote: Hi Tushar, On 14 October 2011 06:40, Tushar Beheratushar.beh...@linaro.org wrote: Hi, In one of the build machines, I am getting following error [1] while building a qemu image with l-m-c using leb build for origen. The build fails only on this one machine. Do yo use same the linaro-image-tools and qemu versions on both machines? Both the machines are using same version of linaro-image-tools. As for qemu versions, the working setup has qemu 0.14.1+ whereas the faulty build machine has qemu 0.14.0+. If this is one concern area, I will upgrade qemu on the faulty build machine and recheck. Does anybody have a clue about what might be wrong with that build machine? The build machine is a x86 based system running Ubuntu 11.04. If any specific information required, please let me know. File ./linaro-image-tools/linaro-media-create, line 156, inmodule verified_files, *hwpacks) File ~/linaro-image-tools/linaro_image_tools/media_create/chroot_utils.py, line 64, in install_hwpacks install_hwpack(chroot_dir, hwpack_file, hwpack_force_yes or hwpack_verified) File ~/linaro-image-tools/linaro_image_tools/media_create/chroot_utils.py, line 85, in install_hwpack cmd_runner.run(args, as_root=True, chroot=chroot_dir).wait() File ~/linaro-image-tools/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/tmpvZJf7s/binary', 'linaro-hwpack-install', '/hwpack_linaro-lt-origen_20110929-0_armel_supported.tar.gz'] returned a non-zero value: 100 [1] http://pastebin.com/AAcCTTi2 -- Regards, Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev Thanks, -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: error while running l-m-c on one build machine
Hi Fathi, On Friday 14 October 2011 04:22 PM, Tushar Behera wrote: Hi Fathi, On Friday 14 October 2011 11:45 AM, Fathi Boudra wrote: Hi Tushar, On 14 October 2011 06:40, Tushar Beheratushar.beh...@linaro.org wrote: Hi, In one of the build machines, I am getting following error [1] while building a qemu image with l-m-c using leb build for origen. The build fails only on this one machine. Do yo use same the linaro-image-tools and qemu versions on both machines? Both the machines are using same version of linaro-image-tools. As for qemu versions, the working setup has qemu 0.14.1+ whereas the faulty build machine has qemu 0.14.0+. If this is one concern area, I will upgrade qemu on the faulty build machine and recheck. I upgraded the faulty machine to 11.10 oneiric. With that, I don't find any error in l-m-c build. Thanks for your time. Does anybody have a clue about what might be wrong with that build machine? The build machine is a x86 based system running Ubuntu 11.04. If any specific information required, please let me know. File ./linaro-image-tools/linaro-media-create, line 156, inmodule verified_files, *hwpacks) File ~/linaro-image-tools/linaro_image_tools/media_create/chroot_utils.py, line 64, in install_hwpacks install_hwpack(chroot_dir, hwpack_file, hwpack_force_yes or hwpack_verified) File ~/linaro-image-tools/linaro_image_tools/media_create/chroot_utils.py, line 85, in install_hwpack cmd_runner.run(args, as_root=True, chroot=chroot_dir).wait() File ~/linaro-image-tools/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/tmpvZJf7s/binary', 'linaro-hwpack-install', '/hwpack_linaro-lt-origen_20110929-0_armel_supported.tar.gz'] returned a non-zero value: 100 [1] http://pastebin.com/AAcCTTi2 -- Regards, Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev Thanks, -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
error while running l-m-c on one build machine
Hi, In one of the build machines, I am getting following error [1] while building a qemu image with l-m-c using leb build for origen. The build fails only on this one machine. Does anybody have a clue about what might be wrong with that build machine? The build machine is a x86 based system running Ubuntu 11.04. If any specific information required, please let me know. File ./linaro-image-tools/linaro-media-create, line 156, in module verified_files, *hwpacks) File ~/linaro-image-tools/linaro_image_tools/media_create/chroot_utils.py, line 64, in install_hwpacks install_hwpack(chroot_dir, hwpack_file, hwpack_force_yes or hwpack_verified) File ~/linaro-image-tools/linaro_image_tools/media_create/chroot_utils.py, line 85, in install_hwpack cmd_runner.run(args, as_root=True, chroot=chroot_dir).wait() File ~/linaro-image-tools/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/tmpvZJf7s/binary', 'linaro-hwpack-install', '/hwpack_linaro-lt-origen_20110929-0_armel_supported.tar.gz'] returned a non-zero value: 100 [1] http://pastebin.com/AAcCTTi2 -- Regards, Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] ARM: EXYNOS4: Setup consistent dma size at boot time
Hi Kukjin,
On Monday 12 September 2011 11:25 AM, Tushar Behera wrote:
Some of the boards under mach-exynos4 initialize frame-buffers
for which the memory requirement is more than 2MB (Nuri board requires
around 4MB, Origen requires around 2.6MB), hence the default dma pool
allocation size of 2MB is not sufficient. The consistent dma size is
hence increased to successfully allocate memory for those boards.
Depends on ARM: Add init_consistent_dma_size()
by Jon Medhurst (99d1717dd7fecf2b10195b0d864323b952b4eba0).
CC: Jon Medhurstt...@yxit.co.uk
Signed-off-by: Tushar Beheratushar.beh...@linaro.org
---
arch/arm/mach-exynos4/cpu.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos4/cpu.c b/arch/arm/mach-exynos4/cpu.c
index 2d8a40c..45d8bfa 100644
--- a/arch/arm/mach-exynos4/cpu.c
+++ b/arch/arm/mach-exynos4/cpu.c
@@ -10,6 +10,7 @@
#includelinux/sched.h
#includelinux/sysdev.h
+#includelinux/dma-mapping.h
#includeasm/mach/map.h
#includeasm/mach/irq.h
@@ -136,6 +137,7 @@ static void exynos4_idle(void)
void __init exynos4_map_io(void)
{
iotable_init(exynos4_iodesc, ARRAY_SIZE(exynos4_iodesc));
+ init_consistent_dma_size(SZ_8M);
/* initialize device information early */
exynos4_default_sdhci0();
Would you please consider this patch for 3.2?
--
Tushar Behera
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V2 1/2] ARM: S3C2410: Add __init attribute to usb_simtec_init()
Hi Sergei, On Saturday 08 October 2011 07:48 PM, Sergei Shtylyov wrote: Hello. On 07-10-2011 15:55, Tushar Behera wrote: usb_simtec_init() references s3c_ohci_set_platdata() which is defined with __init attribute. Hence to remove section mismatch warning, __init attribute is added to usb_simtec_init(). It removes following two warnigs. WARNING: vmlinux.o(.text+0x1460c): Section mismatch in reference from the function usb_simtec_init() to the function .init.text:s3c_ohci_set_platdata() The function usb_simtec_init() references the function __init s3c_ohci_set_platdata(). WARNING: vmlinux.o(.text+0x14650): Section mismatch in reference from the function usb_simtec_init() to the (unknown reference) .init.data:(unknown) The function usb_simtec_init() references the (unknown reference) __initdata (unknown). Signed-off-by: Tushar Beheratushar.beh...@linaro.org [...] diff --git a/arch/arm/mach-s3c2410/usb-simtec.h b/arch/arm/mach-s3c2410/usb-simtec.h index 03842ed..43cc88f 100644 --- a/arch/arm/mach-s3c2410/usb-simtec.h +++ b/arch/arm/mach-s3c2410/usb-simtec.h @@ -12,5 +12,5 @@ * published by the Free Software Foundation. */ -extern int usb_simtec_init(void); +extern int __init usb_simtec_init(void); Function prototypes don't need to be annotated with __init. I agree that function prototypes don't require to be annotated. But, will it not be better to have same annotation for both function prototypes and the function definitions? WBR, Sergei Thanks for your review. -- Tushar Behera ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH V2 2/2] ARM: S3C2410: irq: Remove __init attributes to fix compilation warning
The structure *_irq_driver is passed as a parameter in
sysdev_driver_register(). This in turn would add this structure to a
list which may be traversed later.
Hence, even though the functions referenced through this structure have
__init attribute, we cannot possibly add __initdata attribute to it.
To remove compilation warnings, the functions referenced thorugh this
structure are also defined without __init attribute.
It removes following two warnings.
WARNING: vmlinux.o(.data+0x4f58): Section mismatch in reference from the
variable s3c2416_irq_driver to the function .init.text:s3c2416_irq_add()
The variable s3c2416_irq_driver references the function __init s3c2416_irq_add()
WARNING: vmlinux.o(.data+0x7c50): Section mismatch in reference from the
variable s3c2443_irq_driver to the function .init.text:s3c2443_irq_add()
The variable s3c2443_irq_driver references the function __init s3c2443_irq_add()
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
arch/arm/mach-s3c2416/irq.c |4 ++--
arch/arm/mach-s3c2443/irq.c |4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-s3c2416/irq.c b/arch/arm/mach-s3c2416/irq.c
index 28ad20d..53e8e57 100644
--- a/arch/arm/mach-s3c2416/irq.c
+++ b/arch/arm/mach-s3c2416/irq.c
@@ -194,7 +194,7 @@ static struct irq_chip s3c2416_irq_uart3 = {
/* IRQ initialisation code */
-static int __init s3c2416_add_sub(unsigned int base,
+static int s3c2416_add_sub(unsigned int base,
void (*demux)(unsigned int,
struct irq_desc *),
struct irq_chip *chip,
@@ -213,7 +213,7 @@ static int __init s3c2416_add_sub(unsigned int base,
return 0;
}
-static int __init s3c2416_irq_add(struct sys_device *sysdev)
+static int s3c2416_irq_add(struct sys_device *sysdev)
{
printk(KERN_INFO S3C2416: IRQ Support\n);
diff --git a/arch/arm/mach-s3c2443/irq.c b/arch/arm/mach-s3c2443/irq.c
index 83ecb11..18585dd 100644
--- a/arch/arm/mach-s3c2443/irq.c
+++ b/arch/arm/mach-s3c2443/irq.c
@@ -222,7 +222,7 @@ static struct irq_chip s3c2443_irq_cam = {
/* IRQ initialisation code */
-static int __init s3c2443_add_sub(unsigned int base,
+static int s3c2443_add_sub(unsigned int base,
void (*demux)(unsigned int,
struct irq_desc *),
struct irq_chip *chip,
@@ -241,7 +241,7 @@ static int __init s3c2443_add_sub(unsigned int base,
return 0;
}
-static int __init s3c2443_irq_add(struct sys_device *sysdev)
+static int s3c2443_irq_add(struct sys_device *sysdev)
{
printk(S3C2443: IRQ Support\n);
--
1.7.4.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH V2 0/2] ARM: S3C2410: Remove section mismatch warning
While compiling with s3c2410_defconfig, we receive 4 section mismatch warnings. Patch 1 addresses a couple of warnings related to usb_simtec_init(). Patch 2 addresses mismatch warnings in a couple of mach-*/irq.c files. Changes for V2: * The original patch is splitted to address to different logical solutions. * __initdata attribute is removed from struct sysdev_driver structures and __init attribute is removed from all referenced function definitions. The patches are rebased on v3.1-rc8. They are only build tested, they are not boot tested on any hardware. Tushar Behera (2): ARM: S3C2410: Add __init attribute to usb_simtec_init() ARM: S3C2410: irq: Remove __init attributes to fix compilation warning arch/arm/mach-s3c2410/usb-simtec.c |2 +- arch/arm/mach-s3c2410/usb-simtec.h |2 +- arch/arm/mach-s3c2416/irq.c|4 ++-- arch/arm/mach-s3c2443/irq.c|4 ++-- 4 files changed, 6 insertions(+), 6 deletions(-) -- 1.7.4.1 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH] ARM: S3C2410: Remove section mismatch warning
Some of the functions and structures did not have _init or __initdata
attributes, even though they were referenced from functions / structures
with those attribute, resulting in section mismatches.
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
The patch is rebased on v3.1-rc8.
The patch has only been build tested, they are not boot tested on any
hardware.
arch/arm/mach-s3c2410/usb-simtec.c |2 +-
arch/arm/mach-s3c2410/usb-simtec.h |2 +-
arch/arm/mach-s3c2416/irq.c|2 +-
arch/arm/mach-s3c2440/clock.c |4 ++--
arch/arm/mach-s3c2443/irq.c|2 +-
5 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-s3c2410/usb-simtec.c
b/arch/arm/mach-s3c2410/usb-simtec.c
index 29bd3d9..3a1028c 100644
--- a/arch/arm/mach-s3c2410/usb-simtec.c
+++ b/arch/arm/mach-s3c2410/usb-simtec.c
@@ -104,7 +104,7 @@ static struct s3c2410_hcd_info usb_simtec_info __initdata =
{
};
-int usb_simtec_init(void)
+int __init usb_simtec_init(void)
{
int ret;
diff --git a/arch/arm/mach-s3c2410/usb-simtec.h
b/arch/arm/mach-s3c2410/usb-simtec.h
index 03842ed..43cc88f 100644
--- a/arch/arm/mach-s3c2410/usb-simtec.h
+++ b/arch/arm/mach-s3c2410/usb-simtec.h
@@ -12,5 +12,5 @@
* published by the Free Software Foundation.
*/
-extern int usb_simtec_init(void);
+extern int __init usb_simtec_init(void);
diff --git a/arch/arm/mach-s3c2416/irq.c b/arch/arm/mach-s3c2416/irq.c
index 28ad20d..153cb2f 100644
--- a/arch/arm/mach-s3c2416/irq.c
+++ b/arch/arm/mach-s3c2416/irq.c
@@ -234,7 +234,7 @@ static int __init s3c2416_irq_add(struct sys_device *sysdev)
return 0;
}
-static struct sysdev_driver s3c2416_irq_driver = {
+static struct sysdev_driver s3c2416_irq_driver __initdata = {
.add= s3c2416_irq_add,
};
diff --git a/arch/arm/mach-s3c2440/clock.c b/arch/arm/mach-s3c2440/clock.c
index f9e6bda..3b3bec5 100644
--- a/arch/arm/mach-s3c2440/clock.c
+++ b/arch/arm/mach-s3c2440/clock.c
@@ -108,7 +108,7 @@ static struct clk s3c2440_clk_ac97 = {
.ctrlbit= S3C2440_CLKCON_CAMERA,
};
-static int s3c2440_clk_add(struct sys_device *sysdev)
+static int __init s3c2440_clk_add(struct sys_device *sysdev)
{
struct clk *clock_upll;
struct clk *clock_h;
@@ -137,7 +137,7 @@ static int s3c2440_clk_add(struct sys_device *sysdev)
return 0;
}
-static struct sysdev_driver s3c2440_clk_driver = {
+static struct sysdev_driver s3c2440_clk_driver __initdata = {
.add= s3c2440_clk_add,
};
diff --git a/arch/arm/mach-s3c2443/irq.c b/arch/arm/mach-s3c2443/irq.c
index 83ecb11..1d483d9 100644
--- a/arch/arm/mach-s3c2443/irq.c
+++ b/arch/arm/mach-s3c2443/irq.c
@@ -265,7 +265,7 @@ static int __init s3c2443_irq_add(struct sys_device *sysdev)
return 0;
}
-static struct sysdev_driver s3c2443_irq_driver = {
+static struct sysdev_driver s3c2443_irq_driver __initdata = {
.add= s3c2443_irq_add,
};
--
1.7.4.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] ARM: S3C2410: Remove section mismatch warning
Hi Russell,
On Monday 03 October 2011 03:29 PM, Russell King - ARM Linux wrote:
On Mon, Oct 03, 2011 at 03:10:41PM +0530, Tushar Behera wrote:
Some of the functions and structures did not have _init or __initdata
attributes, even though they were referenced from functions / structures
with those attribute, resulting in section mismatches.
Firstly - it's a good idea to include the warnings which you're fixing
in the commit log text, so that people know exactly what is being fixed.
Thanks for your review.
Sure, I will add it in next revision.
[ snip ]
diff --git a/arch/arm/mach-s3c2416/irq.c b/arch/arm/mach-s3c2416/irq.c
index 28ad20d..153cb2f 100644
--- a/arch/arm/mach-s3c2416/irq.c
+++ b/arch/arm/mach-s3c2416/irq.c
@@ -234,7 +234,7 @@ static int __init s3c2416_irq_add(struct sys_device *sysdev)
return 0;
}
-static struct sysdev_driver s3c2416_irq_driver = {
+static struct sysdev_driver s3c2416_irq_driver __initdata = {
.add= s3c2416_irq_add,
};
I remain entirely unconvinced that this is correct. As a result of
the sysdev_driver_register(s3c2416_sysclass,s3c2416_irq_driver);
call, this structure is placed on a list.
If this structure is marked __initdata, then the memory behind the
structure will be freed and overwritten - however, it's still on a
list which might be walked. Such a walk would cause a kernel oops
or might even be an exploitable security hole if that page ends up
in userspace - especially as said structure contains function calls
which would be called in privileged mode.
The function s3c2416_irq_add() is defined with __init attribute. Also a
cascade of functions called from s3c2416_irq_add() are also defined with
__init attribute.
Would it be a good idea to remove __init attribute of all these
functions (there are 2 of them) called from s3c2416_irq_add() instead?
The same comment applies to the other sysdev driver structures you're
marking __initdata too.
--
Tushar Behera
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH] gpio/samsung: Move SoC specific codes within macro
In drivers/gpio/gpio-samsung.c, there are certain structures
and functions which are not getting used if the particular
CPU is not selected. These code segments are moved under CPU
specific macros to remove compilation warnings.
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
It has been build tested with s3c2410_defconfig, s3c6400_defconfig,
s5p64x0_defconfig, s5pc100_defconfig, s5pv210_defconfig and
exynos4_defconfig.
The patch has been rebased onto
Commit: gpio/samsung: correct pin configuration for S5PC100/S5PC110/EXYNOS4
on git://github.com/kgene/linux-samsung.git (next/topic-gpio-samsung)
drivers/gpio/gpio-samsung.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/gpio/gpio-samsung.c b/drivers/gpio/gpio-samsung.c
index b6be77a..33d62d1 100644
--- a/drivers/gpio/gpio-samsung.c
+++ b/drivers/gpio/gpio-samsung.c
@@ -318,6 +318,7 @@ static unsigned samsung_gpio_getcfg_4bit(struct
samsung_gpio_chip *chip,
return S3C_GPIO_SPECIAL(con);
}
+#ifdef CONFIG_PLAT_S3C24XX
/*
* s3c24xx_gpio_setcfg_abank - S3C24XX style GPIO configuration (Bank A)
* @chip: The gpio chip that is being configured.
@@ -379,7 +380,9 @@ static unsigned s3c24xx_gpio_getcfg_abank(struct
samsung_gpio_chip *chip,
return S3C_GPIO_SFN(con);
}
+#endif
+#if defined(CONFIG_CPU_S5P6440) || defined(CONFIG_CPU_S5P6450)
static int s5p64x0_gpio_setcfg_rbank(struct samsung_gpio_chip *chip,
unsigned int off, unsigned int cfg)
{
@@ -417,6 +420,7 @@ static int s5p64x0_gpio_setcfg_rbank(struct
samsung_gpio_chip *chip,
return 0;
}
+#endif
static void __init samsung_gpiolib_set_cfg(struct samsung_gpio_cfg *chipcfg,
int nr_chips)
@@ -438,10 +442,12 @@ struct samsung_gpio_cfg s3c24xx_gpiocfg_default = {
.get_config = samsung_gpio_getcfg_2bit,
};
+#ifdef CONFIG_PLAT_S3C24XX
static struct samsung_gpio_cfg s3c24xx_gpiocfg_banka = {
.set_config = s3c24xx_gpio_setcfg_abank,
.get_config = s3c24xx_gpio_getcfg_abank,
};
+#endif
static struct samsung_gpio_cfg exynos4_gpio_cfg = {
.set_pull = exynos4_gpio_setpull,
@@ -450,6 +456,7 @@ static struct samsung_gpio_cfg exynos4_gpio_cfg = {
.get_config = samsung_gpio_getcfg_4bit,
};
+#if defined(CONFIG_CPU_S5P6440) || defined(CONFIG_CPU_S5P6450)
static struct samsung_gpio_cfg s5p64x0_gpio_cfg_rbank = {
.cfg_eint = 0x3,
.set_config = s5p64x0_gpio_setcfg_rbank,
@@ -457,6 +464,7 @@ static struct samsung_gpio_cfg s5p64x0_gpio_cfg_rbank = {
.set_pull = samsung_gpio_setpull_updown,
.get_pull = samsung_gpio_getpull_updown,
};
+#endif
static struct samsung_gpio_cfg samsung_gpio_cfgs[] = {
{
@@ -682,6 +690,7 @@ static int samsung_gpiolib_4bit2_output(struct gpio_chip
*chip,
return 0;
}
+#ifdef CONFIG_PLAT_S3C24XX
/* The next set of routines are for the case of s3c24xx bank a */
static int s3c24xx_gpiolib_banka_input(struct gpio_chip *chip, unsigned offset)
@@ -717,6 +726,7 @@ static int s3c24xx_gpiolib_banka_output(struct gpio_chip
*chip,
local_irq_restore(flags);
return 0;
}
+#endif
/* The next set of routines are for the case of s5p64x0 bank r */
--
1.7.4.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH V4] ARM: EXYNOS4: Add machine support for 7 LCD on ORIGEN
ORIGEN board is fitted with 7 LCD panel HV070WSA. The pixel
resolution of the LCD panel is 1024x600.
Also power domain device for LCD0 is registered.
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
Changes for V4:
* Added gpio_free() call
* Removed .refresh value as it was same as default value.
Changes for V3:
* Added error check for gpio request in LCD power function
Changes for V2:
* Added power domain device registration for LCD0
arch/arm/mach-exynos4/Kconfig |3 ++
arch/arm/mach-exynos4/mach-origen.c | 60 +++
2 files changed, 63 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
index 48f18f7..4f28871 100644
--- a/arch/arm/mach-exynos4/Kconfig
+++ b/arch/arm/mach-exynos4/Kconfig
@@ -222,6 +222,9 @@ config MACH_ORIGEN
select S3C_DEV_RTC
select S3C_DEV_WDT
select S3C_DEV_HSMMC2
+ select S5P_DEV_FIMD0
+ select EXYNOS4_DEV_PD
+ select EXYNOS4_SETUP_FIMD0
select EXYNOS4_SETUP_SDHCI
help
Machine support for ORIGEN based on Samsung EXYNOS4210
diff --git a/arch/arm/mach-exynos4/mach-origen.c
b/arch/arm/mach-exynos4/mach-origen.c
index ed59f86..0833fcb 100644
--- a/arch/arm/mach-exynos4/mach-origen.c
+++ b/arch/arm/mach-exynos4/mach-origen.c
@@ -14,16 +14,22 @@
#include linux/platform_device.h
#include linux/io.h
#include linux/input.h
+#include linux/lcd.h
+
+#include video/platform_lcd.h
#include asm/mach/arch.h
#include asm/mach-types.h
#include plat/regs-serial.h
+#include plat/regs-fb-v4.h
#include plat/exynos4.h
#include plat/cpu.h
#include plat/devs.h
#include plat/sdhci.h
#include plat/iic.h
+#include plat/pd.h
+#include plat/fb.h
#include mach/map.h
@@ -79,10 +85,62 @@ static struct s3c_sdhci_platdata origen_hsmmc2_pdata
__initdata = {
.clk_type = S3C_SDHCI_CLK_DIV_EXTERNAL,
};
+static void lcd_hv070wsa_set_power(struct plat_lcd_data *pd, unsigned int
power)
+{
+ int ret;
+
+ if (power)
+ ret = gpio_request_one(EXYNOS4_GPE3(4),
+ GPIOF_OUT_INIT_HIGH, GPE3_4);
+ else
+ ret = gpio_request_one(EXYNOS4_GPE3(4),
+ GPIOF_OUT_INIT_LOW, GPE3_4);
+
+ gpio_free(EXYNOS4_GPE3(4));
+
+ if (ret)
+ pr_err(failed to request gpio for LCD power: %d\n, ret);
+}
+
+static struct plat_lcd_data origen_lcd_hv070wsa_data = {
+ .set_power = lcd_hv070wsa_set_power,
+};
+
+static struct platform_device origen_lcd_hv070wsa = {
+ .name = platform-lcd,
+ .dev.parent = s5p_device_fimd0.dev,
+ .dev.platform_data = origen_lcd_hv070wsa_data,
+};
+
+static struct s3c_fb_pd_win origen_fb_win0 = {
+ .win_mode = {
+ .left_margin= 64,
+ .right_margin = 16,
+ .upper_margin = 64,
+ .lower_margin = 16,
+ .hsync_len = 48,
+ .vsync_len = 3,
+ .xres = 1024,
+ .yres = 600,
+ },
+ .max_bpp= 32,
+ .default_bpp= 24,
+};
+
+static struct s3c_fb_platdata origen_lcd_pdata __initdata = {
+ .win[0] = origen_fb_win0,
+ .vidcon0= VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB,
+ .vidcon1= VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
+ .setup_gpio = exynos4_fimd0_gpio_setup_24bpp,
+};
+
static struct platform_device *origen_devices[] __initdata = {
+ exynos4_device_pd[PD_LCD0],
s3c_device_hsmmc2,
s3c_device_rtc,
s3c_device_wdt,
+ s5p_device_fimd0,
+ origen_lcd_hv070wsa,
};
static void __init origen_map_io(void)
@@ -95,7 +153,9 @@ static void __init origen_map_io(void)
static void __init origen_machine_init(void)
{
s3c_sdhci2_set_platdata(origen_hsmmc2_pdata);
+ s5p_fimd0_set_platdata(origen_lcd_pdata);
platform_add_devices(origen_devices, ARRAY_SIZE(origen_devices));
+ s5p_device_fimd0.dev.parent = exynos4_device_pd[PD_LCD0].dev;
}
MACHINE_START(ORIGEN, ORIGEN)
--
1.7.4.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V4] ARM: EXYNOS4: Add machine support for 7 LCD on ORIGEN
Dear Wolfgang Denk,
On Thursday 15 September 2011 02:44 PM, Wolfgang Denk wrote:
Dear Tushar Behera,
In message1316076867-2138-1-git-send-email-tushar.beh...@linaro.org you
wrote:
ORIGEN board is fitted with 7 LCD panel HV070WSA. The pixel
resolution of the LCD panel is 1024x600.
...
+static struct s3c_fb_pd_win origen_fb_win0 = {
+ .win_mode = {
+ .left_margin= 64,
+ .right_margin = 16,
+ .upper_margin = 64,
+ .lower_margin = 16,
+ .hsync_len = 48,
+ .vsync_len = 3,
+ .xres = 1024,
+ .yres = 600,
+ },
+ .max_bpp= 32,
+ .default_bpp= 24,
+};
Does it still make sense to hard-code such parameters?
In PowerPC-land we pass display mode information in the device tree
using a verbatim EDID block.
Would it be not better (and way more flexible) to do the same here,
now that ARM has device tree support?
Thanks for your suggestions.
Currently work for enabling device tree support for EXYNOS4 based
machine is going on. Once it is done, we should be able to pass this
information through device tree blob.
For non-DT machines, IMHO, we have to follow the current approach.
Best regards,
Wolfgang Denk
--
Tushar Behera
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH V2] ARM: EXYNOS4: Add machine support for 7 LCD on ORIGEN
ORIGEN board is fitted with 7 LCD panel HV070WSA. The pixel
resolution of the LCD panel is 1024x600.
Also power domain device for LCD0 is registered.
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
Changes for V2:
* Added power domain device registration for LCD0
The patch is rebased on [1]. For proper working of LCD on ORIGEN,
following patches are needed. These patches are already submitted to
the mailing list.
a. ARM: EXYNOS4: Add PWM backlight support on Origen
Author: Giridhar Maruthy
b. ARM: EXYNOS4: Configure MAX8997 PMIC for Origen
Author: Inderpal Singh
[1] git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
(for-next)
arch/arm/mach-exynos4/Kconfig |3 ++
arch/arm/mach-exynos4/mach-origen.c | 53 +++
2 files changed, 56 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
index 48f18f7..4f28871 100644
--- a/arch/arm/mach-exynos4/Kconfig
+++ b/arch/arm/mach-exynos4/Kconfig
@@ -222,6 +222,9 @@ config MACH_ORIGEN
select S3C_DEV_RTC
select S3C_DEV_WDT
select S3C_DEV_HSMMC2
+ select S5P_DEV_FIMD0
+ select EXYNOS4_DEV_PD
+ select EXYNOS4_SETUP_FIMD0
select EXYNOS4_SETUP_SDHCI
help
Machine support for ORIGEN based on Samsung EXYNOS4210
diff --git a/arch/arm/mach-exynos4/mach-origen.c
b/arch/arm/mach-exynos4/mach-origen.c
index ed59f86..ed04f63 100644
--- a/arch/arm/mach-exynos4/mach-origen.c
+++ b/arch/arm/mach-exynos4/mach-origen.c
@@ -14,16 +14,22 @@
#include linux/platform_device.h
#include linux/io.h
#include linux/input.h
+#include linux/lcd.h
+
+#include video/platform_lcd.h
#include asm/mach/arch.h
#include asm/mach-types.h
#include plat/regs-serial.h
+#include plat/regs-fb-v4.h
#include plat/exynos4.h
#include plat/cpu.h
#include plat/devs.h
#include plat/sdhci.h
#include plat/iic.h
+#include plat/pd.h
+#include plat/fb.h
#include mach/map.h
@@ -79,10 +85,55 @@ static struct s3c_sdhci_platdata origen_hsmmc2_pdata
__initdata = {
.clk_type = S3C_SDHCI_CLK_DIV_EXTERNAL,
};
+static void lcd_hv070wsa_set_power(struct plat_lcd_data *pd, unsigned int
power)
+{
+ int gpio = EXYNOS4_GPE3(4);
+
+ gpio_request(gpio, GPE3_4);
+ gpio_direction_output(gpio, power);
+ gpio_free(gpio);
+}
+
+static struct plat_lcd_data origen_lcd_hv070wsa_data = {
+ .set_power = lcd_hv070wsa_set_power,
+};
+
+static struct platform_device origen_lcd_hv070wsa = {
+ .name = platform-lcd,
+ .dev.parent = s5p_device_fimd0.dev,
+ .dev.platform_data = origen_lcd_hv070wsa_data,
+};
+
+static struct s3c_fb_pd_win origen_fb_win0 = {
+ .win_mode = {
+ .left_margin= 64,
+ .right_margin = 16,
+ .upper_margin = 64,
+ .lower_margin = 16,
+ .hsync_len = 48,
+ .vsync_len = 3,
+ .xres = 1024,
+ .yres = 600,
+ .refresh= 60,
+ },
+ .max_bpp= 32,
+ .default_bpp= 24,
+};
+
+static struct s3c_fb_platdata origen_lcd_pdata __initdata = {
+ .win[0] = origen_fb_win0,
+ .vidcon0= VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB,
+ .vidcon1= VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
+ .setup_gpio = exynos4_fimd0_gpio_setup_24bpp,
+};
+
static struct platform_device *origen_devices[] __initdata = {
+ exynos4_device_pd[PD_LCD0],
s3c_device_hsmmc2,
s3c_device_rtc,
s3c_device_wdt,
+ s5p_device_fimd0,
+ origen_lcd_hv070wsa,
};
static void __init origen_map_io(void)
@@ -95,7 +146,9 @@ static void __init origen_map_io(void)
static void __init origen_machine_init(void)
{
s3c_sdhci2_set_platdata(origen_hsmmc2_pdata);
+ s5p_fimd0_set_platdata(origen_lcd_pdata);
platform_add_devices(origen_devices, ARRAY_SIZE(origen_devices));
+ s5p_device_fimd0.dev.parent = exynos4_device_pd[PD_LCD0].dev;
}
MACHINE_START(ORIGEN, ORIGEN)
--
1.7.4.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V2] ARM: EXYNOS4: Add machine support for 7 LCD on ORIGEN
Hi Fabio,
On Wednesday 14 September 2011 05:06 PM, Fabio Estevam wrote:
On Wed, Sep 14, 2011 at 8:01 AM, Tushar Beheratushar.beh...@linaro.org wrote:
...
+static void lcd_hv070wsa_set_power(struct plat_lcd_data *pd, unsigned int
power)
+{
+ int gpio = EXYNOS4_GPE3(4);
+
+ gpio_request(gpio, GPE3_4);
+ gpio_direction_output(gpio, power);
You should check for returned errors for these functions.
Ok.
Will this be better?
static void lcd_hv070wsa_set_power(struct plat_lcd_data *pd, \
unsigned int power)
{
int ret;
unsigned long flag = power ? GPIOF_OUT_INIT_HIGH : \
GPIOF_OUT_INIT_LOW;
ret = gpio_request_one(EXYNOS4_GPE3(4), flag, GPE3_4);
if (ret)
printk(KERN_ERR Could not request gpio for LCD power);
}
Regards,
Fabio Estevam
--
Tushar Behera
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V2] ARM: EXYNOS4: Add machine support for 7 LCD on ORIGEN
Hi Fabio Estevam,
On Wednesday 14 September 2011 06:09 PM, Fabio Estevam wrote:
On Wed, Sep 14, 2011 at 9:07 AM, Tushar Beheratushar.beh...@linaro.org wrote:
...
Will this be better?
static void lcd_hv070wsa_set_power(struct plat_lcd_data *pd, \
unsigned int power)
{
int ret;
unsigned long flag = power ? GPIOF_OUT_INIT_HIGH : \
GPIOF_OUT_INIT_LOW;
ret = gpio_request_one(EXYNOS4_GPE3(4), flag, GPE3_4);
if (ret)
printk(KERN_ERR Could not request gpio for LCD power);
}
Looks better. You can use pr_err instead of printk(KERN_ERR .
Thanks for your review comments. I will send the next version with these
changes.
Regards,
Fabio Estevam
--
Tushar Behera
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH V3] ARM: EXYNOS4: Add machine support for 7 LCD on ORIGEN
ORIGEN board is fitted with 7 LCD panel HV070WSA. The pixel
resolution of the LCD panel is 1024x600.
Also power domain device for LCD0 is registered.
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
Changes for V3:
* Added error check for gpio request in LCD power function
Changes for V2:
* Added power domain device registration for LCD0
The patch is rebased on [1]. For proper working of LCD on ORIGEN,
following patches are needed. These patches are already submitted to
the mailing list.
a. ARM: EXYNOS4: Add PWM backlight support on Origen
Author: Giridhar Maruthy
b. ARM: EXYNOS4: Configure MAX8997 PMIC for Origen
Author: Inderpal Singh
[1] git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
(for-next)
arch/arm/mach-exynos4/Kconfig |3 ++
arch/arm/mach-exynos4/mach-origen.c | 54 +++
2 files changed, 57 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
index 48f18f7..4f28871 100644
--- a/arch/arm/mach-exynos4/Kconfig
+++ b/arch/arm/mach-exynos4/Kconfig
@@ -222,6 +222,9 @@ config MACH_ORIGEN
select S3C_DEV_RTC
select S3C_DEV_WDT
select S3C_DEV_HSMMC2
+ select S5P_DEV_FIMD0
+ select EXYNOS4_DEV_PD
+ select EXYNOS4_SETUP_FIMD0
select EXYNOS4_SETUP_SDHCI
help
Machine support for ORIGEN based on Samsung EXYNOS4210
diff --git a/arch/arm/mach-exynos4/mach-origen.c
b/arch/arm/mach-exynos4/mach-origen.c
index ed59f86..0dcd527 100644
--- a/arch/arm/mach-exynos4/mach-origen.c
+++ b/arch/arm/mach-exynos4/mach-origen.c
@@ -14,16 +14,22 @@
#include linux/platform_device.h
#include linux/io.h
#include linux/input.h
+#include linux/lcd.h
+
+#include video/platform_lcd.h
#include asm/mach/arch.h
#include asm/mach-types.h
#include plat/regs-serial.h
+#include plat/regs-fb-v4.h
#include plat/exynos4.h
#include plat/cpu.h
#include plat/devs.h
#include plat/sdhci.h
#include plat/iic.h
+#include plat/pd.h
+#include plat/fb.h
#include mach/map.h
@@ -79,10 +85,56 @@ static struct s3c_sdhci_platdata origen_hsmmc2_pdata
__initdata = {
.clk_type = S3C_SDHCI_CLK_DIV_EXTERNAL,
};
+static void lcd_hv070wsa_set_power(struct plat_lcd_data *pd, unsigned int
power)
+{
+ int ret;
+ unsigned long flag = power ? GPIOF_OUT_INIT_HIGH : GPIOF_OUT_INIT_LOW;
+
+ ret = gpio_request_one(EXYNOS4_GPE3(4), flag, GPE3_4);
+ if (ret)
+ pr_err(Could not request gpio line for LCD power.\n);
+}
+
+static struct plat_lcd_data origen_lcd_hv070wsa_data = {
+ .set_power = lcd_hv070wsa_set_power,
+};
+
+static struct platform_device origen_lcd_hv070wsa = {
+ .name = platform-lcd,
+ .dev.parent = s5p_device_fimd0.dev,
+ .dev.platform_data = origen_lcd_hv070wsa_data,
+};
+
+static struct s3c_fb_pd_win origen_fb_win0 = {
+ .win_mode = {
+ .left_margin= 64,
+ .right_margin = 16,
+ .upper_margin = 64,
+ .lower_margin = 16,
+ .hsync_len = 48,
+ .vsync_len = 3,
+ .xres = 1024,
+ .yres = 600,
+ .refresh= 60,
+ },
+ .max_bpp= 32,
+ .default_bpp= 24,
+};
+
+static struct s3c_fb_platdata origen_lcd_pdata __initdata = {
+ .win[0] = origen_fb_win0,
+ .vidcon0= VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB,
+ .vidcon1= VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
+ .setup_gpio = exynos4_fimd0_gpio_setup_24bpp,
+};
+
static struct platform_device *origen_devices[] __initdata = {
+ exynos4_device_pd[PD_LCD0],
s3c_device_hsmmc2,
s3c_device_rtc,
s3c_device_wdt,
+ s5p_device_fimd0,
+ origen_lcd_hv070wsa,
};
static void __init origen_map_io(void)
@@ -95,7 +147,9 @@ static void __init origen_map_io(void)
static void __init origen_machine_init(void)
{
s3c_sdhci2_set_platdata(origen_hsmmc2_pdata);
+ s5p_fimd0_set_platdata(origen_lcd_pdata);
platform_add_devices(origen_devices, ARRAY_SIZE(origen_devices));
+ s5p_device_fimd0.dev.parent = exynos4_device_pd[PD_LCD0].dev;
}
MACHINE_START(ORIGEN, ORIGEN)
--
1.7.4.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH V2] ARM: EXYNOS4: Add machine support for 7 LCD on ORIGEN
Hi Kukjin,
On Thursday 15 September 2011 10:24 AM, Kukjin Kim wrote:
Tushar Behera wrote:
Hi Fabio,
On Wednesday 14 September 2011 05:06 PM, Fabio Estevam wrote:
On Wed, Sep 14, 2011 at 8:01 AM, Tushar Beheratushar.beh...@linaro.org
wrote:
...
+static void lcd_hv070wsa_set_power(struct plat_lcd_data *pd, unsigned int
power)
+{
+ int gpio = EXYNOS4_GPE3(4);
+
+ gpio_request(gpio, GPE3_4);
+ gpio_direction_output(gpio, power);
You should check for returned errors for these functions.
Ok.
Will this be better?
static void lcd_hv070wsa_set_power(struct plat_lcd_data *pd, \
No need '\'
unsigned int power)
{
int ret;
unsigned long flag = power ? GPIOF_OUT_INIT_HIGH : \
Same as above.
GPIOF_OUT_INIT_LOW;
ret = gpio_request_one(EXYNOS4_GPE3(4), flag, GPE3_4);
if (ret)
printk(KERN_ERR Could not request gpio for LCD power);
}
How about following?
if (power)
ret = gpio_request_one(EXYNOS4_GPE3(4), GPIOF_OUT_INIT_HIGH,
GPE3_4);
else
ret = gpio_request_one(EXYNOS4_GPE3(4), GPIOF_OUT_INIT_LOW,
GPE3_4);
if (ret)
pr_err(failed to request gpio for LCD power: %d\n, ret);
Thanks, I will update accordingly.
Also I will remove the .refresh value as suggested in the other thread.
Thanks.
Best regards,
Kgene.
--
Kukjin Kimkgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
Tushar Behera
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH] ARM: EXYNOS4: Setup consistent dma size at boot time
Some of the boards under mach-exynos4 initialize frame-buffers
for which the memory requirement is more than 2MB (Nuri board requires
around 4MB, Origen requires around 2.6MB), hence the default dma pool
allocation size of 2MB is not sufficient. The consistent dma size is
hence increased to successfully allocate memory for those boards.
Depends on ARM: Add init_consistent_dma_size()
by Jon Medhurst (99d1717dd7fecf2b10195b0d864323b952b4eba0).
CC: Jon Medhurst t...@yxit.co.uk
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
arch/arm/mach-exynos4/cpu.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos4/cpu.c b/arch/arm/mach-exynos4/cpu.c
index 2d8a40c..45d8bfa 100644
--- a/arch/arm/mach-exynos4/cpu.c
+++ b/arch/arm/mach-exynos4/cpu.c
@@ -10,6 +10,7 @@
#include linux/sched.h
#include linux/sysdev.h
+#include linux/dma-mapping.h
#include asm/mach/map.h
#include asm/mach/irq.h
@@ -136,6 +137,7 @@ static void exynos4_idle(void)
void __init exynos4_map_io(void)
{
iotable_init(exynos4_iodesc, ARRAY_SIZE(exynos4_iodesc));
+ init_consistent_dma_size(SZ_8M);
/* initialize device information early */
exynos4_default_sdhci0();
--
1.7.4.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH] ARM: EXYNOS4: convert boot_params to atag_offset
Based on ARM: introduce atag_offset to replace boot_params by Nicolas Pitre (2bb9839e312ed55a6d5824ffa6077ce3d7d63b1e). Since boot_params variable is deleted from machine_desc, the variable is modified in the newer board files. CC: Nicolas Pitre nicolas.pi...@linaro.org Signed-off-by: Tushar Behera tushar.beh...@linaro.org --- This is required when Kukjin's for-next branch is merged with Russell's devel-stable branch. Nicolas's patchset already has changes for other EXYNSO4 based boards. arch/arm/mach-exynos4/mach-origen.c |2 +- arch/arm/mach-exynos4/mach-smdk4212.c |2 +- arch/arm/mach-exynos4/mach-smdkv310.c |2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-exynos4/mach-origen.c b/arch/arm/mach-exynos4/mach-origen.c index ed59f86..b5f6f38 100644 --- a/arch/arm/mach-exynos4/mach-origen.c +++ b/arch/arm/mach-exynos4/mach-origen.c @@ -100,7 +100,7 @@ static void __init origen_machine_init(void) MACHINE_START(ORIGEN, ORIGEN) /* Maintainer: JeongHyeon Kim jh...@insignal.co.kr */ - .boot_params= S5P_PA_SDRAM + 0x100, + .atag_offset= 0x100, .init_irq = exynos4_init_irq, .map_io = origen_map_io, .init_machine = origen_machine_init, diff --git a/arch/arm/mach-exynos4/mach-smdk4212.c b/arch/arm/mach-exynos4/mach-smdk4212.c index 3479a93..8c41ae1 100644 --- a/arch/arm/mach-exynos4/mach-smdk4212.c +++ b/arch/arm/mach-exynos4/mach-smdk4212.c @@ -284,7 +284,7 @@ static void __init smdk4212_machine_init(void) MACHINE_START(SMDK4212, SMDK4212) /* Maintainer: Kukjin Kim kgene@samsung.com */ - .boot_params= S5P_PA_SDRAM + 0x100, + .atag_offset= 0x100, .init_irq = exynos4_init_irq, .map_io = smdk4212_map_io, .init_machine = smdk4212_machine_init, diff --git a/arch/arm/mach-exynos4/mach-smdkv310.c b/arch/arm/mach-exynos4/mach-smdkv310.c index 57cf632..7ce4d8b 100644 --- a/arch/arm/mach-exynos4/mach-smdkv310.c +++ b/arch/arm/mach-exynos4/mach-smdkv310.c @@ -344,7 +344,7 @@ MACHINE_END MACHINE_START(SMDKC210, SMDKC210) /* Maintainer: Kukjin Kim kgene@samsung.com */ - .boot_params= S5P_PA_SDRAM + 0x100, + .atag_offset= 0x100, .init_irq = exynos4_init_irq, .map_io = smdkv310_map_io, .init_machine = smdkv310_machine_init, -- 1.7.4.1 ___ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH] ARM: EXYNOS4: Add machine support for 7 LCD on ORIGEN
ORIGEN board is fitted with 7 LCD panel HV070WSA. The pixel
resolution of the LCD panel is 1024x600.
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
The patch is rebased on [1]. But for proper working of LCD on ORIGEN,
following patches are needed.
a. ARM: EXYNOS4: Add PWM backlight support on Origen
http://www.spinics.net/lists/linux-samsung-soc/msg06309.html
b. ARM: EXYNOS4: Configure MAX8997 PMIC for Origen
http://www.spinics.net/lists/linux-samsung-soc/msg06282.html
[1] git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
arch/arm/mach-exynos4/Kconfig |2 +
arch/arm/mach-exynos4/mach-origen.c | 50 +++
2 files changed, 52 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
index 48f18f7..8656f49 100644
--- a/arch/arm/mach-exynos4/Kconfig
+++ b/arch/arm/mach-exynos4/Kconfig
@@ -222,6 +222,8 @@ config MACH_ORIGEN
select S3C_DEV_RTC
select S3C_DEV_WDT
select S3C_DEV_HSMMC2
+ select S5P_DEV_FIMD0
+ select EXYNOS4_SETUP_FIMD0
select EXYNOS4_SETUP_SDHCI
help
Machine support for ORIGEN based on Samsung EXYNOS4210
diff --git a/arch/arm/mach-exynos4/mach-origen.c
b/arch/arm/mach-exynos4/mach-origen.c
index ed59f86..f2cea78 100644
--- a/arch/arm/mach-exynos4/mach-origen.c
+++ b/arch/arm/mach-exynos4/mach-origen.c
@@ -14,16 +14,21 @@
#include linux/platform_device.h
#include linux/io.h
#include linux/input.h
+#include linux/lcd.h
+
+#include video/platform_lcd.h
#include asm/mach/arch.h
#include asm/mach-types.h
#include plat/regs-serial.h
+#include plat/regs-fb-v4.h
#include plat/exynos4.h
#include plat/cpu.h
#include plat/devs.h
#include plat/sdhci.h
#include plat/iic.h
+#include plat/fb.h
#include mach/map.h
@@ -79,10 +84,54 @@ static struct s3c_sdhci_platdata origen_hsmmc2_pdata
__initdata = {
.clk_type = S3C_SDHCI_CLK_DIV_EXTERNAL,
};
+static void lcd_hv070wsa_set_power(struct plat_lcd_data *pd, unsigned int
power)
+{
+ int gpio = EXYNOS4_GPE3(4);
+
+ gpio_request(gpio, GPE3_4);
+ gpio_direction_output(gpio, power);
+ gpio_free(gpio);
+}
+
+static struct plat_lcd_data origen_lcd_hv070wsa_data = {
+ .set_power = lcd_hv070wsa_set_power,
+};
+
+static struct platform_device origen_lcd_hv070wsa = {
+ .name = platform-lcd,
+ .dev.parent = s5p_device_fimd0.dev,
+ .dev.platform_data = origen_lcd_hv070wsa_data,
+};
+
+static struct s3c_fb_pd_win origen_fb_win0 = {
+ .win_mode = {
+ .left_margin= 64,
+ .right_margin = 16,
+ .upper_margin = 64,
+ .lower_margin = 16,
+ .hsync_len = 48,
+ .vsync_len = 3,
+ .xres = 1024,
+ .yres = 600,
+ .refresh= 60,
+ },
+ .max_bpp= 32,
+ .default_bpp= 24,
+};
+
+static struct s3c_fb_platdata origen_lcd_pdata __initdata = {
+ .win[0] = origen_fb_win0,
+ .vidcon0= VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB,
+ .vidcon1= VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
+ .setup_gpio = exynos4_fimd0_gpio_setup_24bpp,
+};
+
static struct platform_device *origen_devices[] __initdata = {
s3c_device_hsmmc2,
s3c_device_rtc,
s3c_device_wdt,
+ s5p_device_fimd0,
+ origen_lcd_hv070wsa,
};
static void __init origen_map_io(void)
@@ -95,6 +144,7 @@ static void __init origen_map_io(void)
static void __init origen_machine_init(void)
{
s3c_sdhci2_set_platdata(origen_hsmmc2_pdata);
+ s5p_fimd0_set_platdata(origen_lcd_pdata);
platform_add_devices(origen_devices, ARRAY_SIZE(origen_devices));
}
--
1.7.4.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[RESEND PATCH] ARM: EXYNOS4: Add machine support for 7 LCD on ORIGEN
ORIGEN board is fitted with 7 LCD panel HV070WSA. The pixel
resolution of the LCD panel is 1024x600.
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
The original patch-mail bounced back from linux-samsung-...@vger.kernel.org,
hence resending the patch again.
The patch is rebased on [1]. For proper working of LCD on ORIGEN,
following patches are needed. These patches are already submitted to
the mailing list.
a. ARM: EXYNOS4: Add PWM backlight support on Origen
Author: Giridhar Maruthy
b. ARM: EXYNOS4: Configure MAX8997 PMIC for Origen
Author: Inderpal Singh
[1] git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git
arch/arm/mach-exynos4/Kconfig |2 +
arch/arm/mach-exynos4/mach-origen.c | 50 +++
2 files changed, 52 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
index 48f18f7..8656f49 100644
--- a/arch/arm/mach-exynos4/Kconfig
+++ b/arch/arm/mach-exynos4/Kconfig
@@ -222,6 +222,8 @@ config MACH_ORIGEN
select S3C_DEV_RTC
select S3C_DEV_WDT
select S3C_DEV_HSMMC2
+ select S5P_DEV_FIMD0
+ select EXYNOS4_SETUP_FIMD0
select EXYNOS4_SETUP_SDHCI
help
Machine support for ORIGEN based on Samsung EXYNOS4210
diff --git a/arch/arm/mach-exynos4/mach-origen.c
b/arch/arm/mach-exynos4/mach-origen.c
index ed59f86..f2cea78 100644
--- a/arch/arm/mach-exynos4/mach-origen.c
+++ b/arch/arm/mach-exynos4/mach-origen.c
@@ -14,16 +14,21 @@
#include linux/platform_device.h
#include linux/io.h
#include linux/input.h
+#include linux/lcd.h
+
+#include video/platform_lcd.h
#include asm/mach/arch.h
#include asm/mach-types.h
#include plat/regs-serial.h
+#include plat/regs-fb-v4.h
#include plat/exynos4.h
#include plat/cpu.h
#include plat/devs.h
#include plat/sdhci.h
#include plat/iic.h
+#include plat/fb.h
#include mach/map.h
@@ -79,10 +84,54 @@ static struct s3c_sdhci_platdata origen_hsmmc2_pdata
__initdata = {
.clk_type = S3C_SDHCI_CLK_DIV_EXTERNAL,
};
+static void lcd_hv070wsa_set_power(struct plat_lcd_data *pd, unsigned int
power)
+{
+ int gpio = EXYNOS4_GPE3(4);
+
+ gpio_request(gpio, GPE3_4);
+ gpio_direction_output(gpio, power);
+ gpio_free(gpio);
+}
+
+static struct plat_lcd_data origen_lcd_hv070wsa_data = {
+ .set_power = lcd_hv070wsa_set_power,
+};
+
+static struct platform_device origen_lcd_hv070wsa = {
+ .name = platform-lcd,
+ .dev.parent = s5p_device_fimd0.dev,
+ .dev.platform_data = origen_lcd_hv070wsa_data,
+};
+
+static struct s3c_fb_pd_win origen_fb_win0 = {
+ .win_mode = {
+ .left_margin= 64,
+ .right_margin = 16,
+ .upper_margin = 64,
+ .lower_margin = 16,
+ .hsync_len = 48,
+ .vsync_len = 3,
+ .xres = 1024,
+ .yres = 600,
+ .refresh= 60,
+ },
+ .max_bpp= 32,
+ .default_bpp= 24,
+};
+
+static struct s3c_fb_platdata origen_lcd_pdata __initdata = {
+ .win[0] = origen_fb_win0,
+ .vidcon0= VIDCON0_VIDOUT_RGB | VIDCON0_PNRMODE_RGB,
+ .vidcon1= VIDCON1_INV_HSYNC | VIDCON1_INV_VSYNC,
+ .setup_gpio = exynos4_fimd0_gpio_setup_24bpp,
+};
+
static struct platform_device *origen_devices[] __initdata = {
s3c_device_hsmmc2,
s3c_device_rtc,
s3c_device_wdt,
+ s5p_device_fimd0,
+ origen_lcd_hv070wsa,
};
static void __init origen_map_io(void)
@@ -95,6 +144,7 @@ static void __init origen_map_io(void)
static void __init origen_machine_init(void)
{
s3c_sdhci2_set_platdata(origen_hsmmc2_pdata);
+ s5p_fimd0_set_platdata(origen_lcd_pdata);
platform_add_devices(origen_devices, ARRAY_SIZE(origen_devices));
}
--
1.7.4.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH] ARM: EXYNOS4: Add HDMI support for Origen
Hi Deepak,
On Wednesday 07 September 2011 10:17 PM, Deepak Saxena wrote:
Will this patch and the patch Tushar just posted apply
cleanly with each other? You are both touching mach-origen.c,
changing origen_devices, and adding support for video output
so it might be good in a future situations such as this to
post as one patch series with both of your sign-offs.
Thanks for your suggestions.
In the current situation, though the patches touch the same files,
logically they enable unrelated modules. So, would it be good to post
them as part of a single patch series?
And also, we are not sure which patch would go in first. So we thought
it best to rebase both of them to the maintainer tree-top.
For these kind of scenarios, I would better host the patches on my tree
on glo till acceptance from the maintainer.
Thanks,
~Deepak
On 7 September 2011 03:54, Sachin Kamatsachin.ka...@linaro.org wrote:
This patch adds HDMI (TVout) support for Origen board.
This patch is based on for-next branch of Kukjin Kim's tree:
http://git.kernel.org/?p=linux/kernel/git/kgene/linux-samsung.git;a=summary
This patch is tested using Hatim's patch:
http://www.spinics.net/lists/linux-samsung-soc/msg06367.html
Signed-off-by: Sachin Kamatsachin.ka...@linaro.org
---
arch/arm/mach-exynos4/Kconfig |2 ++
arch/arm/mach-exynos4/mach-origen.c |4
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
index 181fb04..4f908f7 100644
--- a/arch/arm/mach-exynos4/Kconfig
+++ b/arch/arm/mach-exynos4/Kconfig
@@ -225,6 +225,8 @@ config MACH_ORIGEN
select S3C_DEV_WDT
select S3C_DEV_HSMMC2
select EXYNOS4_SETUP_SDHCI
+ select S5P_DEV_I2C_HDMIPHY
+ select S5P_DEV_TV
help
Machine support for ORIGEN based on Samsung EXYNOS4210
diff --git a/arch/arm/mach-exynos4/mach-origen.c
b/arch/arm/mach-exynos4/mach-origen.c
index ed59f86..6ec68ee 100644
--- a/arch/arm/mach-exynos4/mach-origen.c
+++ b/arch/arm/mach-exynos4/mach-origen.c
@@ -81,8 +81,11 @@ static struct s3c_sdhci_platdata origen_hsmmc2_pdata
__initdata = {
static struct platform_device *origen_devices[] __initdata = {
s3c_device_hsmmc2,
+s5p_device_i2c_hdmiphy,
s3c_device_rtc,
s3c_device_wdt,
+s5p_device_hdmi,
+s5p_device_mixer,
};
static void __init origen_map_io(void)
@@ -95,6 +98,7 @@ static void __init origen_map_io(void)
static void __init origen_machine_init(void)
{
s3c_sdhci2_set_platdata(origen_hsmmc2_pdata);
+ s5p_i2c_hdmiphy_set_platdata(NULL);
platform_add_devices(origen_devices, ARRAY_SIZE(origen_devices));
}
--
1.7.4.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
--
Tushar Behera
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 3/3] ARM: EXYNOS4: Add support for 8-bit bus width in SDHCI for ORIGEN
On Wednesday 31 August 2011 06:31 AM, Kukjin Kim wrote:
Tushar Behera wrote:
Platform data for SDHCI controller on ORIGEN board is missing the
support for 8-bit bus width. The platform data is extended in sync
with other EXYNOS4 machines.
Signed-off-by: Tushar Beheratushar.beh...@linaro.org
---
arch/arm/mach-exynos4/mach-origen.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos4/mach-origen.c
b/arch/arm/mach-exynos4/mach-
origen.c
index ae18812..6b6cd77 100644
--- a/arch/arm/mach-exynos4/mach-origen.c
+++ b/arch/arm/mach-exynos4/mach-origen.c
@@ -75,11 +75,19 @@ static struct s3c2410_uartcfg origen_uartcfgs[]
__initdata =
{
static struct s3c_sdhci_platdata origen_hsmmc0_pdata __initdata = {
.cd_type= S3C_SDHCI_CD_INTERNAL,
.clk_type = S3C_SDHCI_CLK_DIV_EXTERNAL,
+#ifdef CONFIG_EXYNOS4_SDHCI_CH0_8BIT
+ .max_width = 8,
+ .host_caps = MMC_CAP_8_BIT_DATA,
+#endif
};
static struct s3c_sdhci_platdata origen_hsmmc2_pdata __initdata = {
.cd_type= S3C_SDHCI_CD_INTERNAL,
.clk_type = S3C_SDHCI_CLK_DIV_EXTERNAL,
+#ifdef CONFIG_EXYNOS4_SDHCI_CH2_8BIT
+ .max_width = 8,
+ .host_caps = MMC_CAP_8_BIT_DATA,
+#endif
};
static struct platform_device *origen_devices[] __initdata = {
--
1.7.4.1
Hi Tushar,
I wonder the bus width of SDHCI controller can be changed manually on ORIGEN
like SMDK board.
Thanks for your review.
On ORIGEN board, we have wire connections for HSMMC-0/2/3 between the
MMC port and the SoC. Hence ideally we can work with HSMMC2 in both
4-bit and 8-bit mode. However HSMMC0 can only work in 4-bit mode.
Also IIRC WLAN would be using HSMMC-3 controller for its operations. So
we would have conflict when HSMMC2 is working in 8-bit mode and WLAN is
also enabled. Hence it appears better to drop this patch now.
Thanks.
Best regards,
Kgene.
--
Kukjin Kimkgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
Tushar Behera
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 2/3] ARM: EXYNOS4: Add support for secondary MMC port on ORIGEN
Hi Kukjin,
On Wednesday 31 August 2011 06:23 AM, Kukjin Kim wrote:
Tushar Behera wrote:
-Original Message-
From: Tushar Behera [mailto:tushar.beh...@linaro.org]
Sent: Friday, August 26, 2011 6:39 PM
To: linux-samsung-...@vger.kernel.org
Cc: linaro-dev@lists.linaro.org; kgene@samsung.com; patc...@linaro.org
Subject: [PATCH 2/3] ARM: EXYNOS4: Add support for secondary MMC port on
ORIGEN
Secondary MMC port on ORIGEN is connected to sdhci instance 0. Support
for secondary MMC port is extended by registering sdhci instance 0.
Since sdhci instance 2 can contain a bootable media, sdhci instance 0
is registered after instance 2.
Would be helpful if above comments could be included in codes :)
Signed-off-by: Tushar Beheratushar.beh...@linaro.org
---
arch/arm/mach-exynos4/Kconfig |1 +
arch/arm/mach-exynos4/mach-origen.c |7 +++
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos4/Kconfig b/arch/arm/mach-exynos4/Kconfig
index e6925de..4c14d5e 100644
--- a/arch/arm/mach-exynos4/Kconfig
+++ b/arch/arm/mach-exynos4/Kconfig
@@ -229,6 +229,7 @@ config MACH_ORIGEN
select CPU_EXYNOS4210
select S3C_DEV_RTC
select S3C_DEV_WDT
+ select S3C_DEV_HSMMC
select S3C_DEV_HSMMC2
select EXYNOS4_SETUP_SDHCI
help
diff --git a/arch/arm/mach-exynos4/mach-origen.c
b/arch/arm/mach-exynos4/mach-
origen.c
index e280270..ae18812 100644
--- a/arch/arm/mach-exynos4/mach-origen.c
+++ b/arch/arm/mach-exynos4/mach-origen.c
@@ -72,6 +72,11 @@ static struct s3c2410_uartcfg origen_uartcfgs[]
__initdata = {
},
};
+static struct s3c_sdhci_platdata origen_hsmmc0_pdata __initdata = {
+ .cd_type= S3C_SDHCI_CD_INTERNAL,
+ .clk_type = S3C_SDHCI_CLK_DIV_EXTERNAL,
+};
+
static struct s3c_sdhci_platdata origen_hsmmc2_pdata __initdata = {
.cd_type= S3C_SDHCI_CD_INTERNAL,
.clk_type = S3C_SDHCI_CLK_DIV_EXTERNAL,
@@ -79,6 +84,7 @@ static struct s3c_sdhci_platdata origen_hsmmc2_pdata
__initdata = {
static struct platform_device *origen_devices[] __initdata = {
s3c_device_hsmmc2,
+ s3c_device_hsmmc0,
s3c_device_rtc,
s3c_device_wdt,
};
@@ -93,6 +99,7 @@ static void __init origen_map_io(void)
static void __init origen_machine_init(void)
{
s3c_sdhci2_set_platdata(origen_hsmmc2_pdata);
+ s3c_sdhci0_set_platdata(origen_hsmmc0_pdata);
platform_add_devices(origen_devices, ARRAY_SIZE(origen_devices));
}
--
1.7.4.1
OK, will apply.
If you don't mind, I will add comments the reason of the ordering when I
apply this.
Thanks. That would be great.
Thanks.
Best regards,
Kgene.
--
Kukjin Kimkgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
Tushar Behera
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
Re: [PATCH 3/3] ARM: EXYNOS4: Add support for 8-bit bus width in SDHCI for ORIGEN
Hi Kukjin,
On Wednesday 31 August 2011 06:31 AM, Kukjin Kim wrote:
Tushar Behera wrote:
Platform data for SDHCI controller on ORIGEN board is missing the
support for 8-bit bus width. The platform data is extended in sync
with other EXYNOS4 machines.
Signed-off-by: Tushar Beheratushar.beh...@linaro.org
---
arch/arm/mach-exynos4/mach-origen.c |8
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-exynos4/mach-origen.c
b/arch/arm/mach-exynos4/mach-
origen.c
index ae18812..6b6cd77 100644
--- a/arch/arm/mach-exynos4/mach-origen.c
+++ b/arch/arm/mach-exynos4/mach-origen.c
@@ -75,11 +75,19 @@ static struct s3c2410_uartcfg origen_uartcfgs[]
__initdata =
{
static struct s3c_sdhci_platdata origen_hsmmc0_pdata __initdata = {
.cd_type= S3C_SDHCI_CD_INTERNAL,
.clk_type = S3C_SDHCI_CLK_DIV_EXTERNAL,
+#ifdef CONFIG_EXYNOS4_SDHCI_CH0_8BIT
+ .max_width = 8,
+ .host_caps = MMC_CAP_8_BIT_DATA,
+#endif
};
static struct s3c_sdhci_platdata origen_hsmmc2_pdata __initdata = {
.cd_type= S3C_SDHCI_CD_INTERNAL,
.clk_type = S3C_SDHCI_CLK_DIV_EXTERNAL,
+#ifdef CONFIG_EXYNOS4_SDHCI_CH2_8BIT
+ .max_width = 8,
+ .host_caps = MMC_CAP_8_BIT_DATA,
+#endif
};
static struct platform_device *origen_devices[] __initdata = {
--
1.7.4.1
Hi Tushar,
I wonder the bus width of SDHCI controller can be changed manually on ORIGEN
like SMDK board.
I will do further test and update you about the results.
Thanks.
Best regards,
Kgene.
--
Kukjin Kimkgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
Tushar Behera
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
[PATCH 1/3] ARM: EXYNOS4: Fix sdhci card detection for ORIGEN
Fix incorrect value of cd_type field in platform data for sdhci
device.
Based on ARM: EXYNOS4: Fix card detection for sdhci 0 and 2.
commit a0d8efedb203b5b908dd46cea38201761e2380f9
Signed-off-by: Tushar Behera tushar.beh...@linaro.org
---
arch/arm/mach-exynos4/mach-origen.c |4 +---
1 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-exynos4/mach-origen.c
b/arch/arm/mach-exynos4/mach-origen.c
index ed59f86..e280270 100644
--- a/arch/arm/mach-exynos4/mach-origen.c
+++ b/arch/arm/mach-exynos4/mach-origen.c
@@ -73,9 +73,7 @@ static struct s3c2410_uartcfg origen_uartcfgs[] __initdata = {
};
static struct s3c_sdhci_platdata origen_hsmmc2_pdata __initdata = {
- .cd_type= S3C_SDHCI_CD_GPIO,
- .ext_cd_gpio= EXYNOS4_GPK2(2),
- .ext_cd_gpio_invert = 1,
+ .cd_type= S3C_SDHCI_CD_INTERNAL,
.clk_type = S3C_SDHCI_CLK_DIV_EXTERNAL,
};
--
1.7.4.1
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
