Re: Anybody working on tidspbridge?
On Thu, Jul 10, 2014 at 12:11 PM, Greg KH gre...@linuxfoundation.org wrote: On Thu, Jul 10, 2014 at 08:54:18AM +0300, Ivaylo Dimitrov wrote: On 9.07.2014 10:07, Tony Lindgren wrote: * Suman Anna s-a...@ti.com [140708 11:40]: Hi Peter, On 07/08/2014 09:36 AM, Greg KH wrote: On Tue, Jul 08, 2014 at 03:03:58PM +0200, Peter Meerwald wrote: Hello, Given the total lack of response here, I suggest just deleting the driver. No one has ever done the real work that is going to be required to get this code out of staging. It has had build errors causing it to not even be usable for some kernel versions with no one noticing, so I doubt anyone cares about it anymore here. Cc'ing some more people who might be interested. If no one offers to work on the driver in the next couple of days, I'll send a patch to remove it. I'm using the driver (with kernel 3.7) and it works reasonably well for me; removing it seems a bit harsh. Using it is different from being able to maintain the code and move it out of the staging tree. Also, 3.7 is really old and obsolete, not much we can do with that kernel version :) Are you able to work on the code and do the effort needed to get it out of the staging tree? If so, great, if not, we are going to have to delete it, sorry. I agree with Greg here. In fact, the current TODO does not do enough justice to the amount of work required to make it even work on the latest kernel. Most of the TIers who worked on this driver have moved on as Kristina would have figured with her bounced emails. So I do suggest that this driver be deleted from the kernel tree. If there are enough number of folks using it (not sure how many are out there), it can be worked on out-of-tree and brought back in a cleaner fashion rather than keeping a broken stale driver in the kernel. I agree, not much has improved with this driver since it got added into staging except just compile fixes. Regards, Tony Well, recently I've sent a couple of patches which implement stuff from TODO [1]. However, with the migration to DT, my focus now is to have a kernel/userspace that boots at all and this leaves no free cycles for DSP. Maybe tidspbridge can be left in staging until DT migration is finished, that way me (and maybe other people) will have the time needed to try to implement what remains in TODO. Also, keep in mind there will (hopefully) be another omap3 end-user device released by the end of the year (Neo900), which most probably will gain more developers interested in fixing the DSP driver. I'm really tired of people saying, maybe sometime in the future we will work on this for this driver. It's not the first time I've heard it, and it has _never_ come true. Honestly, I really don't believe it will ever happen, given that TI doesn't care about this code at all. If in the future, someone does want to work on this, a simple revert of the patch that removes the driver will be all that is needed. Let's do that instead of hoping that sometime, someone, somewhere, will do this work. Makes sense to me. FYI, it will come back again on newer TI ARM+DSP devices. Those aren't going away, but I'm also not aware of anyone imminently pushing patches. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
On Thu, Jun 26, 2014 at 9:06 AM, Tom Rini tr...@ti.com wrote: On 06/26/2014 03:50 AM, Tony Lindgren wrote: * Gupta, Pekon pe...@ti.com [140618 01:52]: Hi, From: Jason Kridner [mailto:jkrid...@gmail.com] On Tue, Jun 17, 2014 at 3:11 AM, Gupta, Pekon pe...@ti.com wrote: From: Jason Kridner [...] * The devicetree sources, including the primary boot .dts files, will eventually be removed from the kernel source tree. I'm not too sure if and when it'll really happen, but starting up a project to maintain the definitive beagleboard.org board devicetree files outside the kernel seems to make sense. Given the interdependency of the boot .dtb and the overlay .dtbo files, combining them into a single repository where every distribution can pick them up seems like a natural and obvious choice. There are of course some dependencies on kernel versions, but I believe most of those have settled out by now and we should be OK moving forward. +1 Yes, moving cape DTS out of kernel tree should help developers. There are quite a few cape patches floating in mail-lists, but as cape DTS is still not accepted in mainline so they get lost and forgotten. So one place for collecting all this is a good idea. However, somehow the universal I/O DTS looked seemed complicated: (1) All capes work standalone, but due to share pin-mux some cape combinations cannot be used simultaneously. But most users of BeagleBone are already well-versed with DT and kernel infrastructure, so they need not be spoon fed to get a out-of-box working solution for each combination. If there is proper documentation is available about compatibility of capes with each other, then users will figure out themselves. I think you have too much confidence in users. If this doesn't hurt power users, then why is it bad have an option to spoon feed? This doesn't prevent anyone with knowledge of DT from doing their own thing. Fair enough. But plz give a try to u-boot alternative below. It works at my end. (2) Also, there was a talk of enabling and disabling DT fragments via u-boot. That should also be explored instead of complicating cape DTS. Link? Relevance? we can modify DT from u-boot itself [1]. Example: MMC2 pin-mux conflicts with NAND and NOR capes. But using following sequence of commands, you can modify DTB via u-boot and make NAND cape work _without_any_hack_ in patch [2]. /* load DTB */ u-boot tftp 0x8100 am335x-boneblack.dtb u-boot fdt addr 0x8100 /* disable MMC2 node */ u-boot fdt list /ocp/mmc@481d8000 u-boot fdt set /ocp/mmc@481d8000 status \d\i\s\a\b\l\e\d u-boot fdt list /ocp/mmc@481d8000 status /* enable GPMC node */ u-boot fdt list /ocp/gpmc u-boot fdt set /ocp/gpmc status \o\k\a\y u-boot fdt list /ocp/gpmc status /* enable ELM node */ u-boot fdt list /ocp/elm u-boot fdt set /ocp/elm status \o\k\a\y u-boot fdt list /ocp/elm status /* boot uImage */ tftp 0x8200 uImage bootm 0x8200 - 0x8100 Note: fdt set command does not accept string literals as binding values, it internally converts them to string, so escape sequenced characters were used here.. okay == \o\k\a\y disabled == \d\i\s\a\b\l\e\d Hope above solves the pre-requisite because of which 'Tony Lindgren t...@atomide.com' was unable to accept cape related DTS into his tree [3] Yes. If the capes are disabled by default we can have at least some of them included in the mainline kernel and enabled by the bootloader as needed. I'd like to hear back from the u-boot people too on this approach naturally. Great. And some things we still cannot merge if they overlap for GPMC bindings for example. So we have to carefully check the generated .dtb file with dtc -I dtb -O dts. This sounds really problematic to me from an end-user horror point of view. And fortunately 3.17 is going to have some level of overlay support so we can set this problem aside (and even treat the am335x gp evm profileN trees as overlays too). Thank you Tom for chiming in. I think the end user experience is horrific. Pekon should at least provide patches to u-boot that would provide a mechanism to enable/disable a cape with a single operation, rather than the individual devicetree nodes. This seems to really break any ability to keep information about a cape consolidated or usable by mere mortals. I don't know that pushing it all into the kernel with overlays, however, is the right answer. We've seen challenges with some userspaces not exposing /lib/firmware in time and needing to compile overlays into the kernel to make them work. More troublesome are the types of errors end-users get when there are syntax errors, conflicts or other failures, most notably because testing of loading all of the various overlays in conflict with each other is adhoc at best. We've gotten a lot of good feedback on using the pinmux-helper and config-pin utility from end users who are still struggling to learn how to do devicetree
Re: [PATCH v1 3/3] ARM: dts: am335x-bone: add support for beaglebone LCD4 cape
On Wed, Jun 25, 2014 at 1:49 AM, Gupta, Pekon pe...@ti.com wrote:
From: Jason Kridner [mailto:jkrid...@gmail.com]
On Tue, Jun 24, 2014 at 8:24 AM, Pekon Gupta pe...@ti.com wrote:
This patch adds support for LCD4 cape as advertised on
http://elinux.org/CircuitCo:BeagleBone_LCD4
[...]
diff --git a/arch/arm/boot/dts/am335x-bone-display-cape.dts
b/arch/arm/boot/dts/am335x-bone-
display-cape.dts
If this is mean to be included, why not use the .dtsi extension rather
than .dts. .dts implies it is a top-level file.
I followed the ideology given in in below discussion
http://comments.gmane.org/gmane.linux.drivers.devicetree/13921
As I understood .dtsi file extension should be used for silicon DT data which
which remains common for all the boards using that silicon (like am33xx.dtsi).
And .dts is for board specific DT data.
However, anything works for me, as its just matter of file-name-extension.
So should I rename all files to .dtsi ?
I believe the thread is not thinking of board-level as being add-on
boards. I don't think it disagrees that if it is an include file, it
should be called .dtsi. If it is called .dts, the assumption should be
that it results in a .dtb (or .dtbo if for an overlay --- not yet a
solution in mainline).
[...]
+/ {
+ backlight {
+ status = disabled;
+ compatible = gpio-backlight;
+ pinctrl-names = default;
+ pinctrl-0 = bbcape_backlight_pins;
+ gpios = gpio1 18 GPIO_ACTIVE_HIGH;
+ default-on;
+ };
+
+ panel {
+ status = disabled;
Where are you expecting to enable this? I'm guessing through your
u-boot hacking? Certainly I can see editing the boot script to make
this work, but I don't see how this results in the average user simply
plugging in the cape and having it work without having to edit files.
Yes, using u-boot commands, *without touching any source file*.
I'm planning to send patch for adding following helper commands in u-boot
u-boot fdt node enable node-path
u-boot fdt node disable node-path
If that's accepted, enabling disabling capes will become very easy.
And, as you said user can put these commands in scripts (like Uenv.txt)
or environment variable, and execute them automatically at each boot.
Perhaps you can put some real logic into the bootloader that looks at
the cape EEPROMs?
No, I don't want to go the EEPROM way, because of reasons suggested
in earlier mail. It's not scalable, especially when you don't have control
over what type and how third-party is developing the capes.
Well, I have no interest in needing to manually switch my uEnv.txt
file based on whatever cape I have installed. Your patches to put
by-default-disabled disabled support for various capes into the the
main .dtb feels useful to me. I'm just going to optimize my systems to
utilize the EEPROM (when provided) to trigger loading the
configuration for me.
Have you considered using tools like pinmux-helper as is done with the
cape-universal overlay?
https://github.com/beagleboard/devicetree-source/blob/master/arch/arm/boot/dts/cape-universal-
00A0.dts
Yes, I have seen that. In pin-mux helper pins are configured not based on
their actual names but as they appear on P8 and P9 headers of Beaglebone.
- For shared pins, you have defined all possible functionality.
- For dedicated pins, there is single fragment.
Now there are two questions..
(1) Do we need to update this cape-universal-xx.dts everytime a new
Cape in market uses some dedicated pin for some muxed functionality ?
cape-universalXXX.dts needs to be moved into the main .dtb (via
.dtsi). Can you give an example of what you mean by shared pins and
dedicated pins here? It seems to me all the pins have multiple
fragments except ADC pins and perhaps the I2C port used for expansion
EEPROMs, but even that one CAN be muxed.
(2) I'm not sure but kernel does _not_ free the memory allocated to
DT fragment. If so, this universal fragment which has pin-mux for all
P8 and P9 pins will block the memory forever. Would be good to know
the in-memory size required for this universal fragment ?
How can I check easily? Obviously loading all of these drivers is
going to have an impact.
I've been hacking with adding all of these pinmux helpers to the main
.dts. I think you are encouraging me to add it to include files to
make it a bit more granular.
http://paste.debian.net/106319/
Yes, using include files would be good.
Also one minor feedback. Please use macros for Pin directions, Pulls, etc
instead of hex numbers, it make it more readable. And then you don't need
to specify that in comments.
- 0xa0 0x08/* lcd_data0.lcd_data0, OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT |
AM33XX_PULL_DISA */
+ 0xa0 (OMAP_MUX_MODE0 | AM33XX_PIN_OUTPUT | AM33XX_PULL_DISA)/*
lcd_data0.lcd_data0 */
If those are supported in the syntax and exist in some headers, I will use them.
I appreciate
Re: [PATCH v1 3/3] ARM: dts: am335x-bone: add support for beaglebone LCD4 cape
On Tue, Jun 24, 2014 at 8:24 AM, Pekon Gupta pe...@ti.com wrote:
This patch adds support for LCD4 cape as advertised on
http://elinux.org/CircuitCo:BeagleBone_LCD4
This cape has:
* 480x272 TFT-LCD panel
- LCD panel datasheet and timing information are sourced from [1]
- LCD backlight is connected to 'EHRPWM1A' on cape board, but its used for
enabling backlight power-supply. So 'gpio-backlight' driver is used instead
of 'pwm-backlight' driver (Kconfig: BACKLIGHT_GPIO=y).
* 4-wire resistive Touchscreen
*Known constrains*
As LCD panel pins (lcd_data, hsync, vsync, pclk) are shared with on-board
NXP HDMI framer, so either HDMI or LCD-cape can be used at time. Thus while
using this cape 'hdmi' DT node needs to be disabled in am335x-boneblack.dts
[1] www.newhavendisplay.com/specs/NHD-4.3-480272MF-ATXI-T-1.pdf
www.newhavendisplay.com/app_notes/OTA5180A.pdf
Signed-off-by: Pekon Gupta pe...@ti.com
---
arch/arm/boot/dts/am335x-bone-display-cape.dts | 104
+
arch/arm/boot/dts/am335x-bone.dts | 1 +
arch/arm/boot/dts/am335x-boneblack.dts | 1 +
3 files changed, 106 insertions(+)
create mode 100644 arch/arm/boot/dts/am335x-bone-display-cape.dts
diff --git a/arch/arm/boot/dts/am335x-bone-display-cape.dts
b/arch/arm/boot/dts/am335x-bone-display-cape.dts
If this is mean to be included, why not use the .dtsi extension rather
than .dts. .dts implies it is a top-level file.
new file mode 100644
index 000..f3b7cef
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-bone-display-cape.dts
@@ -0,0 +1,104 @@
+/*
+ * Copyright (C) 2014 Texas Instruments Incorporated - http://www.ti.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.
+ *
+ * This DTS adds supports for display capes using LCD interface for display
+ * and GPIO or PWM interface for backlight controls.
+ */
+
+
+am33xx_pinmux {
+ bbcape_backlight_pins: bbcape_backlight_pins {
+ pinctrl-single,pins =
+ 0x48 (PIN_OUTPUT | MUX_MODE7) /*
gpmc_a[2].GPIO1[18] (backlight control) */
+ ;
+ };
+
+ bbcape_lcd_pins: bbcape_lcd_pins {
+ pinctrl-single,pins =
+ 0xa0 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data0.lcd_data0 */
+ 0xa4 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data1.lcd_data1 */
+ 0xa8 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data2.lcd_data2 */
+ 0xac (PIN_OUTPUT | MUX_MODE0) /*
lcd_data3.lcd_data3 */
+ 0xb0 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data4.lcd_data4 */
+ 0xb4 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data5.lcd_data5 */
+ 0xb8 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data6.lcd_data6 */
+ 0xbc (PIN_OUTPUT | MUX_MODE0) /*
lcd_data7.lcd_data7 */
+ 0xc0 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data8.lcd_data8 */
+ 0xc4 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data9.lcd_data9 */
+ 0xc8 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data10.lcd_data10 */
+ 0xcc (PIN_OUTPUT | MUX_MODE0) /*
lcd_data11.lcd_data11 */
+ 0xd0 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data12.lcd_data12 */
+ 0xd4 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data13.lcd_data13 */
+ 0xd8 (PIN_OUTPUT | MUX_MODE0) /*
lcd_data14.lcd_data14 */
+ 0xdc (PIN_OUTPUT | MUX_MODE0) /*
lcd_data15.lcd_data15 */
+ 0xe0 (PIN_OUTPUT | MUX_MODE0) /*
lcd_vsync.lcd_vsync */
+ 0xe4 (PIN_OUTPUT | MUX_MODE0) /*
lcd_hsync.lcd_hsync */
+ 0xe8 (PIN_OUTPUT | MUX_MODE0) /*
lcd_pclk.lcd_pclk */
+ 0xec (PIN_OUTPUT | MUX_MODE0) /*
lcd_ac_bias_en.lcd_ac_bias_en (lcd_en) */
+ 0x1a4 (PIN_OUTPUT_PULLUP | MUX_MODE7) /*
mcasp0_fsr.gpio3[19] (lcd_disen) */
+ ;
+ };
+
+ bbcape_touchscreen_pins: bbcape_touchscreen_pins {
+ pinctrl-single,pins =
+ 0x184 (PIN_INPUT_PULLDOWN | MUX_MODE7) /*
uart1_txd.gpio0[15] (enter) */
+ 0x40 (PIN_INPUT_PULLDOWN | MUX_MODE7) /*
gpmc_a0.gpio1[16] (left) */
+ 0x44 (PIN_INPUT_PULLDOWN | MUX_MODE7) /*
gpmc_a1.gpio1[17] (right) */
+ 0x4c (PIN_INPUT_PULLDOWN | MUX_MODE7) /*
gpmc_a3.gpio1[19] (up) */
+ 0x198 (PIN_INPUT_PULLDOWN |
Re: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for beaglebone NAND cape
On Mon, Jun 23, 2014 at 1:48 AM, Tony Lindgren t...@atomide.com wrote:
* Gupta, Pekon pe...@ti.com [140622 22:42]:
Hi Tony,
Just reviving this thread for some information..
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Monday, May 19, 2014 9:56 PM
To: Gupta, Pekon
Cc: linux-omap; Ezequiel Garcia; Stefan Roese; Javier Martinez Canillas;
Quadros, Roger
Subject: Re: [PATCH v7 1/4] ARM: dts: am335x-bone: add support for
beaglebone NAND cape
* Pekon Gupta pe...@ti.com [140519 02:16]:
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -9,6 +9,7 @@
#include am33xx.dtsi
#include am335x-bone-common.dtsi
+#include am335x-bone-memory-cape.dts
ldo3_reg {
regulator-min-microvolt = 180;
--- a/arch/arm/boot/dts/am335x-boneblack.dts
+++ b/arch/arm/boot/dts/am335x-boneblack.dts
@@ -9,6 +9,7 @@
#include am33xx.dtsi
#include am335x-bone-common.dtsi
+#include am335x-bone-memory-cape.dts
ldo3_reg {
regulator-min-microvolt = 180;
Based on the recent discussions on the capes, it seems that nobody
wants to implement toggling of the capes in u-boot. And as there
can be other capes using GPMC bus, we can't merge this.
I have been able to get toggling of capes (enabling and disabling of DT
nodes)
in u-boot. It was already there in u-boot mainline [1], may be no-body tried
it.
Example: Below sequence works for NAND cape patch mentioned in this thread.
---
/* load DTB */
u-boot tftp 0x8100 am335x-boneblack.dtb
u-boot fdt addr 0x8100
/* disable MMC2 node */
u-boot fdt list /ocp/mmc@481d8000
u-boot fdt set /ocp/mmc@481d8000 status \d\i\s\a\b\l\e\d
u-boot fdt list /ocp/mmc@481d8000 status
/* enable GPMC node */
u-boot fdt list /ocp/gpmc
u-boot fdt set /ocp/gpmc status \o\k\a\y
u-boot fdt list /ocp/gpmc status
/* enable ELM node */
u-boot fdt list /ocp/elm
u-boot fdt set /ocp/elm status \o\k\a\y
u-boot fdt list /ocp/elm status
/* boot uImage */
tftp 0x8200 uImage
bootm 0x8200 - 0x8100
Note: fdt set command does not accept string literals
as binding values, it internally converts them to string, so
escape sequenced characters were used here..
okay == \o\k\a\y
disabled == \d\i\s\a\b\l\e\d
Cool. Now all we need is a few helper functions in u-boot
so it can be done a bit easier :)
The association of devicetree overlay files in /lib/firmware to cape
IDs made it where the kernel-based cape overlay manager could modify
the devicetree as needed without putting extensive cape-specific logic
in the kernel or bootloader. Throwing a bunch of capes into a single
class of capes won't save any work there. If we can get the bootloader
to support the .dtbo files, then we can continue to use the ID in the
cape to provide all the DT modifications we need. If we need to do
scripts for the modifications, we'd still need to associate the cape
ID to that script.
This still doesn't cover the need for run-time devicetree
modification, but I'll leave that for the other on-going thread.
I do agree with the idea of moving more of the potential sources of
conflict that can be resolved out of the overlays and into the main
devicetree, leaving the overlays or scripts simply to deal with the
conflicts that cannot be resolved at run-time given the current
infrastructure. I just think they should go into .dtsi (include) files
for the main .dts/.dtb files for the boards, rather than additional
overlays or alternative .dts files.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
On Tue, Jun 17, 2014 at 12:01 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Tue, Jun 17, 2014 at 04:32:11PM +0300, Pantelis Antoniou wrote: The complexity is absolutely required, and it has nothing to do with beaglebone capes. The fact of the matter is that reconfigurable hardware is here, on shipping system, and we, as the linux kernel community have to make sure it works, and that it works in a sane way. Right, so looking back in the git history, this project has been going on for... at least four years? Probably longer than the length of time that we've been converting ARM to DT. At no point during that has anyone brought up the issue of DT being dynamic, so none of the drivers which we have been converting caters for this. Isn't this a bit of a missed opportunity, if this is a direction that OF wishes to head towards? I believe it absolutely is a missed opportunity, but that doesn't mean it isn't still needed moving forward. We've been using overlays successfully in the BeagleBoard.org community on BeagleBone Black for over a year now. It is just a shame we're still shipping a 3.8 kernel. This universal overlay provides hope to support most add-ons, but it doesn't address the dynamic nature of some add-on hardware. It is certainly my hope that this effort doesn't derail the overlay development work. Wouldn't it have been relevant to the discussion at kernel summit too, concerning DRM/v4l2/componentised systems? What if someone comes along tomorrow with part of their multimedia based system inside a FPGA which they program up at runtime? -- FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly improving, and getting towards what was expected from it. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
On Tue, Jun 17, 2014 at 3:11 AM, Gupta, Pekon pe...@ti.com wrote: Hi Jason, From: Jason Kridner Adding devicetree and linux-arm-kernel lists based on feedback on IRC... On Tue, Jun 10, 2014 at 12:46 PM, Jason Kridner jkrid...@gmail.com wrote: I'd like to discuss moving our current library of cape devicetree overlay sources into a single tree, including the boot .dtb files for BeagleBoard.org boards and moving towards enabling as much of the cape support into a single boot-time .dtb file with an approach similar to the cape-universal overlay (https://github.com/cdsteinkuehler/beaglebone-universal-io), but not in an overlay. First of all, I want to note this doesn't change my view on the importance of mainline support for devicetree overlays. They are still absolutely critical and highly useful, solving problems that cannot be solved through boot-time devicetrees. I'm simply looking for an approach that will complement the availability of overlays and provide the best user experience. Robert has been talking about the actions required to clean-up Debian Jessie support in another thread (https://groups.google.com/d/msg/beagleboard/2b8rArtfABY/A8d1JzmJa4IJ) and I suggested we should add a bit of a detour by cleaning up the cape support for the mainline kernel and switching away our primary process of supporting capes from using overlays to using a single devicetree file provided at boot. I promised a pull-request and hadn't gotten around to sending it until now (below). No architecture changes have been made in my pull-request, just bringing in the kernel devicetree source history. This suggestion is based on several assumptions, any number of which might be wrong. The assumptions (for which I'm looking for feedback/corrections): * The overlays pretty much all need to be compiled into the kernel if they are going to be loaded using kernel command-line arguments or /etc/capemgr for the majority of distros. While many cape devicetree use cases are perfectly happy with loading at run-time rather than boot-time, it seems there should be a mechanism for pushing cape support into the category of being available at boot-time across distributions. * The devicetree sources, including the primary boot .dts files, will eventually be removed from the kernel source tree. I'm not too sure if and when it'll really happen, but starting up a project to maintain the definitive beagleboard.org board devicetree files outside the kernel seems to make sense. Given the interdependency of the boot .dtb and the overlay .dtbo files, combining them into a single repository where every distribution can pick them up seems like a natural and obvious choice. There are of course some dependencies on kernel versions, but I believe most of those have settled out by now and we should be OK moving forward. +1 Yes, moving cape DTS out of kernel tree should help developers. There are quite a few cape patches floating in mail-lists, but as cape DTS is still not accepted in mainline so they get lost and forgotten. So one place for collecting all this is a good idea. However, somehow the universal I/O DTS looked seemed complicated: (1) All capes work standalone, but due to share pin-mux some cape combinations cannot be used simultaneously. But most users of BeagleBone are already well-versed with DT and kernel infrastructure, so they need not be spoon fed to get a out-of-box working solution for each combination. If there is proper documentation is available about compatibility of capes with each other, then users will figure out themselves. I think you have too much confidence in users. If this doesn't hurt power users, then why is it bad have an option to spoon feed? This doesn't prevent anyone with knowledge of DT from doing their own thing. (2) Also, there was a talk of enabling and disabling DT fragments via u-boot. That should also be explored instead of complicating cape DTS. Link? Relevance? (3) BeagleBone community and outside are coming out with new featured capes, which might possess a challenge to get a absolute non-conflicting universal I/O DTS. What might be working today might have conflicts tomorrow with introduction of new capes. We should be open to be compatible to capes developed outside Beaglebone.org. In my view this is important for longer term. Example: http://valentfx.com/logi-bone/ The tree isn't only for beagleboard.org, but anyone building add-on boards for beagleboard.org boards. In fact, there are 0 official add-on boards from beagleboard.org as of now. CircuitCo makes a bunch and I believe there are some coming from TI soon, but there are none from beagleboard.org itself and most capes come from other parties. Registry is at http://beaglebonecapes.com and http://beagleboard.org/cape. So, plz review my feedback and if you plan to create an external tree for beaglebone Capes, I would be happy to submit some cape patches. Great. https
Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
Adding devicetree and linux-arm-kernel lists based on feedback on IRC... On Tue, Jun 10, 2014 at 12:46 PM, Jason Kridner jkrid...@gmail.com wrote: I'd like to discuss moving our current library of cape devicetree overlay sources into a single tree, including the boot .dtb files for BeagleBoard.org boards and moving towards enabling as much of the cape support into a single boot-time .dtb file with an approach similar to the cape-universal overlay (https://github.com/cdsteinkuehler/beaglebone-universal-io), but not in an overlay. First of all, I want to note this doesn't change my view on the importance of mainline support for devicetree overlays. They are still absolutely critical and highly useful, solving problems that cannot be solved through boot-time devicetrees. I'm simply looking for an approach that will complement the availability of overlays and provide the best user experience. Robert has been talking about the actions required to clean-up Debian Jessie support in another thread (https://groups.google.com/d/msg/beagleboard/2b8rArtfABY/A8d1JzmJa4IJ) and I suggested we should add a bit of a detour by cleaning up the cape support for the mainline kernel and switching away our primary process of supporting capes from using overlays to using a single devicetree file provided at boot. I promised a pull-request and hadn't gotten around to sending it until now (below). No architecture changes have been made in my pull-request, just bringing in the kernel devicetree source history. This suggestion is based on several assumptions, any number of which might be wrong. The assumptions (for which I'm looking for feedback/corrections): * The overlays pretty much all need to be compiled into the kernel if they are going to be loaded using kernel command-line arguments or /etc/capemgr for the majority of distros. While many cape devicetree use cases are perfectly happy with loading at run-time rather than boot-time, it seems there should be a mechanism for pushing cape support into the category of being available at boot-time across distributions. * The devicetree sources, including the primary boot .dts files, will eventually be removed from the kernel source tree. I'm not too sure if and when it'll really happen, but starting up a project to maintain the definitive beagleboard.org board devicetree files outside the kernel seems to make sense. Given the interdependency of the boot .dtb and the overlay .dtbo files, combining them into a single repository where every distribution can pick them up seems like a natural and obvious choice. There are of course some dependencies on kernel versions, but I believe most of those have settled out by now and we should be OK moving forward. * There seems to be little or no interest in my previous proposal to use cape EEPROMs to store the overlay fragments. Given some churn in the devicetree node definitions, it is likely this would have failed in bad ways anyway. It seems mostly reasonable to expect users to update their kernel and firmware to gain support for new add-on hardware and we mostly try to avoid regressions (with the seemingly ever-living exception of 3D graphics support), so I think I'm better aligned with the community to drop my older suggestion. Some people, including CircuitCo, are building capes without configuration EEPROMs now, so a different recommended mechanism seems like a requirement. * With the patches in our vendor 3.8 kernels and with all recent mainline kernels, performing userspace muxing operations has become easy again. It seems to be possible to turn on drivers not currently in use without an unacceptable level of bloat or conflict. This has been partially proven out using Charles' universal cape (https://github.com/cdsteinkuehler/beaglebone-universal-io), though I still have some concerns about conflicts. The result might be that there is still some number of overlays, but the approach of minimizing the overlays and instead relying on the existing loading/unloading mechanisms of the mainline drivers as much as possible feels right to me. * It will still be some time before devicetree overlay support is adopted in the mainline kernel. While I still see a strong need to have devicetree overlay support and CapeMgr in the mainline, the desire here is to optimize the user experience in the shortest term possible. Users get really confused by the errors that get generated by loading incorrect devicetree overlays and it is always nice when you can avoid confusing users. My suggestion is: * Maintain the source for .dtb and .dtbo files for all BeagleBoard.org boards at http://github.com/beagleboard/devicetree-source, overriding the sources in the mainline kernel when performing kernel builds. We can host pre-built .dtb and .dtbo files at a normailzed location outside the source repository for those that don't want to perform the builds, since I don't believe the binary
Unifying cape overlays into boot .dtb for BeagleBoard.org boards
I'd like to discuss moving our current library of cape devicetree overlay sources into a single tree, including the boot .dtb files for BeagleBoard.org boards and moving towards enabling as much of the cape support into a single boot-time .dtb file with an approach similar to the cape-universal overlay (https://github.com/cdsteinkuehler/beaglebone-universal-io), but not in an overlay. First of all, I want to note this doesn't change my view on the importance of mainline support for devicetree overlays. They are still absolutely critical and highly useful, solving problems that cannot be solved through boot-time devicetrees. I'm simply looking for an approach that will complement the availability of overlays and provide the best user experience. Robert has been talking about the actions required to clean-up Debian Jessie support in another thread (https://groups.google.com/d/msg/beagleboard/2b8rArtfABY/A8d1JzmJa4IJ) and I suggested we should add a bit of a detour by cleaning up the cape support for the mainline kernel and switching away our primary process of supporting capes from using overlays to using a single devicetree file provided at boot. I promised a pull-request and hadn't gotten around to sending it until now (below). No architecture changes have been made in my pull-request, just bringing in the kernel devicetree source history. This suggestion is based on several assumptions, any number of which might be wrong. The assumptions (for which I'm looking for feedback/corrections): * The overlays pretty much all need to be compiled into the kernel if they are going to be loaded using kernel command-line arguments or /etc/capemgr for the majority of distros. While many cape devicetree use cases are perfectly happy with loading at run-time rather than boot-time, it seems there should be a mechanism for pushing cape support into the category of being available at boot-time across distributions. * The devicetree sources, including the primary boot .dts files, will eventually be removed from the kernel source tree. I'm not too sure if and when it'll really happen, but starting up a project to maintain the definitive beagleboard.org board devicetree files outside the kernel seems to make sense. Given the interdependency of the boot .dtb and the overlay .dtbo files, combining them into a single repository where every distribution can pick them up seems like a natural and obvious choice. There are of course some dependencies on kernel versions, but I believe most of those have settled out by now and we should be OK moving forward. * There seems to be little or no interest in my previous proposal to use cape EEPROMs to store the overlay fragments. Given some churn in the devicetree node definitions, it is likely this would have failed in bad ways anyway. It seems mostly reasonable to expect users to update their kernel and firmware to gain support for new add-on hardware and we mostly try to avoid regressions (with the seemingly ever-living exception of 3D graphics support), so I think I'm better aligned with the community to drop my older suggestion. Some people, including CircuitCo, are building capes without configuration EEPROMs now, so a different recommended mechanism seems like a requirement. * With the patches in our vendor 3.8 kernels and with all recent mainline kernels, performing userspace muxing operations has become easy again. It seems to be possible to turn on drivers not currently in use without an unacceptable level of bloat or conflict. This has been partially proven out using Charles' universal cape (https://github.com/cdsteinkuehler/beaglebone-universal-io), though I still have some concerns about conflicts. The result might be that there is still some number of overlays, but the approach of minimizing the overlays and instead relying on the existing loading/unloading mechanisms of the mainline drivers as much as possible feels right to me. * It will still be some time before devicetree overlay support is adopted in the mainline kernel. While I still see a strong need to have devicetree overlay support and CapeMgr in the mainline, the desire here is to optimize the user experience in the shortest term possible. Users get really confused by the errors that get generated by loading incorrect devicetree overlays and it is always nice when you can avoid confusing users. My suggestion is: * Maintain the source for .dtb and .dtbo files for all BeagleBoard.org boards at http://github.com/beagleboard/devicetree-source, overriding the sources in the mainline kernel when performing kernel builds. We can host pre-built .dtb and .dtbo files at a normailzed location outside the source repository for those that don't want to perform the builds, since I don't believe the binary format is changing any time soon other than the overlay support we utilize. Any patches accepted into mainline as long as these files still exist there as well should be merged to try to keep these in-line as long as
Re: Unifying cape overlays into boot .dtb for BeagleBoard.org boards
Adding devicetree and linux-arm-kernel lists based on feedback on IRC... On Tue, Jun 10, 2014 at 12:46 PM, Jason Kridner jkrid...@gmail.com wrote: I'd like to discuss moving our current library of cape devicetree overlay sources into a single tree, including the boot .dtb files for BeagleBoard.org boards and moving towards enabling as much of the cape support into a single boot-time .dtb file with an approach similar to the cape-universal overlay (https://github.com/cdsteinkuehler/beaglebone-universal-io), but not in an overlay. First of all, I want to note this doesn't change my view on the importance of mainline support for devicetree overlays. They are still absolutely critical and highly useful, solving problems that cannot be solved through boot-time devicetrees. I'm simply looking for an approach that will complement the availability of overlays and provide the best user experience. Robert has been talking about the actions required to clean-up Debian Jessie support in another thread (https://groups.google.com/d/msg/beagleboard/2b8rArtfABY/A8d1JzmJa4IJ) and I suggested we should add a bit of a detour by cleaning up the cape support for the mainline kernel and switching away our primary process of supporting capes from using overlays to using a single devicetree file provided at boot. I promised a pull-request and hadn't gotten around to sending it until now (below). No architecture changes have been made in my pull-request, just bringing in the kernel devicetree source history. This suggestion is based on several assumptions, any number of which might be wrong. The assumptions (for which I'm looking for feedback/corrections): * The overlays pretty much all need to be compiled into the kernel if they are going to be loaded using kernel command-line arguments or /etc/capemgr for the majority of distros. While many cape devicetree use cases are perfectly happy with loading at run-time rather than boot-time, it seems there should be a mechanism for pushing cape support into the category of being available at boot-time across distributions. * The devicetree sources, including the primary boot .dts files, will eventually be removed from the kernel source tree. I'm not too sure if and when it'll really happen, but starting up a project to maintain the definitive beagleboard.org board devicetree files outside the kernel seems to make sense. Given the interdependency of the boot .dtb and the overlay .dtbo files, combining them into a single repository where every distribution can pick them up seems like a natural and obvious choice. There are of course some dependencies on kernel versions, but I believe most of those have settled out by now and we should be OK moving forward. * There seems to be little or no interest in my previous proposal to use cape EEPROMs to store the overlay fragments. Given some churn in the devicetree node definitions, it is likely this would have failed in bad ways anyway. It seems mostly reasonable to expect users to update their kernel and firmware to gain support for new add-on hardware and we mostly try to avoid regressions (with the seemingly ever-living exception of 3D graphics support), so I think I'm better aligned with the community to drop my older suggestion. Some people, including CircuitCo, are building capes without configuration EEPROMs now, so a different recommended mechanism seems like a requirement. * With the patches in our vendor 3.8 kernels and with all recent mainline kernels, performing userspace muxing operations has become easy again. It seems to be possible to turn on drivers not currently in use without an unacceptable level of bloat or conflict. This has been partially proven out using Charles' universal cape (https://github.com/cdsteinkuehler/beaglebone-universal-io), though I still have some concerns about conflicts. The result might be that there is still some number of overlays, but the approach of minimizing the overlays and instead relying on the existing loading/unloading mechanisms of the mainline drivers as much as possible feels right to me. * It will still be some time before devicetree overlay support is adopted in the mainline kernel. While I still see a strong need to have devicetree overlay support and CapeMgr in the mainline, the desire here is to optimize the user experience in the shortest term possible. Users get really confused by the errors that get generated by loading incorrect devicetree overlays and it is always nice when you can avoid confusing users. My suggestion is: * Maintain the source for .dtb and .dtbo files for all BeagleBoard.org boards at http://github.com/beagleboard/devicetree-source, overriding the sources in the mainline kernel when performing kernel builds. We can host pre-built .dtb and .dtbo files at a normailzed location outside the source repository for those that don't want to perform the builds, since I don't believe the binary
Re: [PATCH v4 1/4] ARM: dts: am335x-bone: add CD for mmc1
On Thu, Sep 12, 2013 at 2:35 PM, Koen Kooi k...@dominion.thruhere.net wrote:
From: Alexander Holler hol...@ahsoftware.de
This enables the use of MMC cards even when no card was inserted at boot.
Signed-off-by: Alexander Holler hol...@ahsoftware.de
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
Acked-by: Jason Kridner j...@ti.com
---
arch/arm/boot/dts/am335x-bone-common.dtsi | 14 ++
arch/arm/boot/dts/am335x-bone.dts | 1 -
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi
b/arch/arm/boot/dts/am335x-bone-common.dtsi
index 2f66ded..0d95d54 100644
--- a/arch/arm/boot/dts/am335x-bone-common.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
@@ -107,6 +107,12 @@
0x14c (PIN_INPUT_PULLDOWN | MUX_MODE7)
;
};
+
+ mmc1_pins: pinmux_mmc1_pins {
+ pinctrl-single,pins =
+ 0x160 (PIN_INPUT | MUX_MODE7) /* GPIO0_6 */
+ ;
+ };
};
ocp {
@@ -260,3 +266,11 @@
pinctrl-0 = davinci_mdio_default;
pinctrl-1 = davinci_mdio_sleep;
};
+
+mmc1 {
+ status = okay;
+ pinctrl-names = default;
+ pinctrl-0 = mmc1_pins;
+ cd-gpios = gpio0 6 GPIO_ACTIVE_HIGH;
+ cd-inverted;
+};
diff --git a/arch/arm/boot/dts/am335x-bone.dts
b/arch/arm/boot/dts/am335x-bone.dts
index d5f43fe..0d63348 100644
--- a/arch/arm/boot/dts/am335x-bone.dts
+++ b/arch/arm/boot/dts/am335x-bone.dts
@@ -17,6 +17,5 @@
};
mmc1 {
- status = okay;
vmmc-supply = ldo3_reg;
};
--
1.8.2.1
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AM335x mpurate + bogomips
On Thu, Feb 21, 2013 at 11:36 AM, Mark Jackson mpfj-l...@mimc.co.uk wrote: Before I dig any deeper, can anyone tell me if the bootarg mpurate is meant to be supported for AM335x SoCs ? I've tried it on our custom board using 3v8, but no joy. The boot log shows:- [0.00] Booting Linux on physical CPU 0x0 [0.00] Linux version 3.8.0-03059-g621553c-dirty (mpfj@mpfj-nanobone) (gcc version 4.5.4 (Buildroot 2012.11) ) #113 SMP Thu Feb 21 16:29:48 GMT 2013 [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache [0.00] Machine: Generic AM33XX (Flattened Device Tree), model: Newflow NanoBone [0.00] Memory policy: ECC disabled, Data cache writeback [0.00] CPU: All CPU(s) started in SVC mode. [0.00] AM335X ES1.0 (neon ) ... [0.00] Kernel command line: console=ttyO0,115200n8 mpurate=720 root=/dev/mmcblk0p2 ro rootfstype=ext2 rootwait ... [0.001119] Calibrating delay loop... 364.48 BogoMIPS (lpj=1425408) I don't think mpurate does anything on AM335x, though I could be wrong---just that I've not heard of anyone using it for any purpose. The BogoMIPS values don't seem to be very useful. I'm not sure of their purpose, but the hopefully useful information I can offer you is that if you are running a kernel supporting dynamic frequency scaling on AM335x, the number tends to be lower. I have seen other boot logs outputs [1] from other people where they are getting nearly double that. Looking at omap2xxx_clk_arch_init(), only ompa24xx devices are supported. Am I missing something obvious (like it's not yet supported !!) ? Use the cpufreq tools to determine and set the frequency. Cheers Mark J. [1] http://e2e.ti.com/support/embedded/linux/f/354/t/245316.aspx -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [U-Boot] [RFC] Kbuild support for ARM FIT images
On Thu, Feb 21, 2013 at 9:22 PM, Jason Gunthorpe jguntho...@obsidianresearch.com wrote: On Thu, Feb 21, 2013 at 06:19:05PM -0600, Rob Herring wrote: The desired FPGA use case is DT updates after booting the kernel. This has nothing to do with FIT images. And if the FPGA tools generate the DTB, then it is certainly not tied to the kernel. Completely unrelated, but do you have any pointer for how to do this? Hot plugging a 'dtb fragment' into the kernel would be really handy.. This doesn't answer the full question on how FPGA tools generate DTB, but it is a huge problem for BeagleBone add-on hardware that we have some mechanism to dynamically load DT fragments. Pantelis posted some work in that direction[1] and has continued development of his patches and we've been using those extensively with BeagleBone kernel development[2]. It would be great if the FPGA folks would get on-board in supporting the dynamically loadable DT overlay fragments by reviewing and supporting upstream acceptance of the code. [1] http://lwn.net/Articles/531569/ [2] http://github.com/beagleboard/kernel/tree/3.8 I'm thinking something like adding a tree below a PCI controller describing a PCI device and sub nodes, similar to what Thierry was doing for his Avionics. How would interrupt maps and phandles be managed across the main dtb and the 'hot plugged' dtb? Regards, Jason ___ U-Boot mailing list u-b...@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
On Fri, Nov 2, 2012 at 7:21 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: Fair enough. But there's no such thing a 'hotplug enumeration construct' in Linux yet, and a bus is the closest thing to it. It does take advantage of the nice way device code matches drivers and devices though. A bus is the wrong construct. You need something to add devices onto the busses. You can do that. The Intel SFI layer on phones for example enumerates devices through a firmware table set and creates them on the right actual physical bus not on their own fake one. Physically, it is a bus, though it is made up of several other busses. While I could certainly see people using the mechanism for enumerating soldered-down devices over the fixed busses, there is a physical connector that deserves some abstraction/identification. Further, it is critical to enable hardware vendors to avoid writing any code for which there are existing drivers. It's not hotplug in the sense that the phone happens be a fixed configuration but it does support hotplug behaviour because the order of the drivers and enumeration is undefined (and both orders work). I think SFI is interesting, but certainly lacks all of the interfaces. It seems reasonable to me to extend the specification to add the missing interfaces, but what doesn't seem to map is the fact that the SFI structures are initially processed in the bootloader and passed statically to the kernel, rather than enabling run-time operation. Users may make run-time trade-offs and also need mechanisms for performing initial debug on products like proto capes. Capebus seems to me to provide this solution fairly well. I don't believe the SFI approach covers the most critical aspects of hotplug behaviour. I'm afraid that having the I2C/SPI drivers doing the detection won't work. The capes can have arbitrary I2C/SPI devices (and even more weird components). There is no way to assure for example that the I2C device responding to address 'foo' in cape A is the same I2C device responding to the same address in cape B. your -detect() method should take care of that. There isn't some magical serial number in I²C devices that a -detect() method can read and the implementation of I²C is somewhat It doesn't matter. What you are basically talking about is cape layer - wtf is this - how do I plumb it - create device nodes with correct name for binding, address etc on the right bus i2c layer - ooh a new i2c device - probe as indicated by device name - attach correct driver Many of the devices cannot be probed. Architecturally its possible you want to make some caps MFDs if they have their own bus heirarchies etc but generally I doubt it. Take a look at arch/x86/platform/mrst/mrst.c. It's a specific example of a platform which parses tables and attaches devices to the right physical bus in a manner they can be reliably probed even when the device has no sane autodetect. I know I *am* the slow person in the room, but doesn't this approach require the code to be compiled into the kernel to support the devices ahead of time? While I think it might be reasonable to have hardware developers provide DT fragments in their EEPROMs, there's no way to get them to submit code patches in order to get their hardware to work. They need to ship hardware that works with pre-existing software, since there will be hundreds of boards created by people with little to no previous Linux experience (akin to Arduino). I seem to be missing how that approach would get us there. Alan -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
My apologies for starting a new thread, but I don't have this thread in my Inbox. http://www.spinics.net/lists/linux-omap/msg81034.html Tony Lindgren wrote: * Pantelis Antoniou panto@xxx [121031 15:02]: So when device's node is 'disabled' of_platform_device_create_pdata() will not create the device. Now, of course it is possible to re-trigger the platform's probe method to be called, and in fact I do so in the capebus patches. You should fix this in generic way then rather than working around it in capebus. The same problem exists changing between different functionality for the shared pins, let's say between USB pins and UART pins if you want a serial debug console on some phone. The current capebus solution goes a long way to fixing a huge issue for BeagleBone users and I don't understand what seems to be a push-back on principle. On BeagleBone capes, these conflicts cannot be resolved early. Do you have suggestions on some more generic method? It seems to me the proposed capebus approach strikes a good balance. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Current state of AM33xx patches
From: Daniel Mack zon...@gmail.com Hey, can anybody give me a quick wrap-up about the current state of AM33xx based SoCs in mainline? What are the next steps to get things merged? There is a wiki page [1] that is intended to provide a summary, but I'm confident it is not up-to-date. There is also some automated testing, but I'm not aware if any of the test results are public and I believe the coverage is fairly limited. Hopefully Carlos can chime in with any information about that. [1] http://processors.wiki.ti.com/index.php/Sitara_Linux_Upstream_Status#AM335x _Status I'm getting involved in a project that is based on a AM3352 and would like to provide help where necessary and wanted. Your help is really appreciated, so thanks in advance. Hopefully Vaibhav or Chase can reply with info about any particular subsystems that need either review or coding. Conversion to Device Tree is an on-going complex area where Vaibhav is contributing. Thanks, Daniel -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Staging tree for AM335x platforms
Tony, I'm looking at creating a public repository to hold patches not yet in shape for inclusion in linux-omap (if not personally, then someone at TI that meets the below charter). I know there can be concern that this becomes a distraction if we start pulling in community patches. It seems it needs to be coupled with reworking systems for acceptance upstream, but we'd like for there to be something where community members can generate patches against while we are in the process of cleaning up the underlying platform bits. Do you have any recommendations or guidelines that should be followed regarding anything about such a public repository? Recommendations and guidelines can include, but not be limited to, where the repository should live, where patches and pull requests should be submitted, what types of patches should be accepted and what state they should be in, when should it be rebased, who is suitable to maintain this repository and what should be used for managing patch status (ie. patchwork and which patchwork). If this doesn't sound useful to you, then please feel free to shut me down on this. The goal is to help and it is understood that contributions to the infrastructure (dev tree, pwr mgmt, etc.) are required to be productive. Regards, Jason -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Staging tree for AM335x platforms
On Wed, Sep 21, 2011 at 4:23 PM, Tony Lindgren t...@atomide.com wrote: Hi, * Jason Kridner jkrid...@beagleboard.org [110921 10:56]: Tony, I'm looking at creating a public repository to hold patches not yet in shape for inclusion in linux-omap (if not personally, then someone at TI that meets the below charter). I know there can be concern that this becomes a distraction if we start pulling in community patches. It seems it needs to be coupled with reworking systems for acceptance upstream, but we'd like for there to be something where community members can generate patches against while we are in the process of cleaning up the underlying platform bits. OK cool. Do you have any recommendations or guidelines that should be followed regarding anything about such a public repository? Recommendations and guidelines can include, but not be limited to, where the repository should live, where patches and pull requests should be submitted, what types of patches should be accepted and what state they should be in, when should it be rebased, who is suitable to maintain this repository and what should be used for managing patch status (ie. patchwork and which patchwork). Well in general the thing to watch out for is once you create a tree it becomes a complete mess in about three months. Or else it just becomes a graveyard of unmergeable patches :) I'm not going to advertise a tree here and on the beagle list until I'm confident I can stick with it a couple of years consistently. I like to keep some labels on old stuff, but I would commit to having it rebased frequently and tested in an automated fashion. So keeping that in mind, ideally your tree would be just a daily merge of various driver developers branches. And then try to set up things where the responsibility of merging code upstream is on the drivers developers. Trying to merge other people's patches upstream is not scalable. Understood. I'd be looking for contributors to show some commitment or drop their patches. I'm sure there will be a certain amount of fire-and-forget patches coming from people that I'll want to try to push for them, but I'll try to shed the cruft frequently. Other than that, you should be able to base it on some recent mainline tag and pick in some queued up patches as needed. If this doesn't sound useful to you, then please feel free to shut me down on this. The goal is to help and it is understood that contributions to the infrastructure (dev tree, pwr mgmt, etc.) are required to be productive. That totally sounds usable to me :) Assuming you can figure out some way to address the comments above. For helping with contributions, I can think of a few places where help is badly needed: 1. Remove dependencies in mainline kernel that block merging Maybe you can isolate some issues in mainline kernel that cause you problems merging your patches upstream? If so, whatever is needed should be done to patch away those dependencies. At least PM patches fit into this category.. Makes sense. 2. Merge all am335x/beagle clone board-*.c files together This would help a lot when we start converting drivers to use device tree as it reduces the number of board-*.c files Sounds like a good task and something I can tackle. I got some push-back on this from internal developers, but I think I can start merging some of it myself and send some code to ask advice on how to make it most maintainable. 3. Help with device tree conversion of device drivers Which drivers do most am335x and beagle clones use? Maybe you can help converting those drivers to use device tree? USB, GPIO, I2C and SPI are most critical from my perspective. I need to figure out which of those already have some owners pushing them ahead. Sure some drivers depend on regulator framework conversion and the device tree omap_device glue layer, but there are already patches being posted for those Great. I guess it makes sense for this tree to include those patches and hopefully the thrash when they change won't be unbearable. I won't know until I start doing it. :-) Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
omap kernel mirror?
On Fri, Sep 16, 2011 at 6:33 PM, Peter Lyon lordva...@gmail.com wrote: With kernel.org down for maintenance, what is the recommended git mirror to use instead of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git? Mainline is temporarily available at https://github.com/torvalds/linux. linux-omap is temporarily available at https://github.com/tmlind/linux. Thanks, Peter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [beagleboard] EHCI softirq kernel panic
On Tue, Aug 9, 2011 at 1:51 PM, Joel A Fernandes agnel.j...@gmail.com wrote: Anyone seen this before? A lot of the kernel developers don't frequent the beagleboard list. If you think it is a general kernel bug, I suspect you want to copy linux-omap. Trying to boot 3.0.0 with OE patches from an SD Card, and with a network cable connected results in the following traceback. Not connecting a network cable makes the errors go away. [ 83.386779] Process gtk-update-icon (pid: 351, stack limit = 0xdd95c2f0) [ 83.393798] Stack: (0xdd95dfb0 to 0xdd95e000) [ 83.398345] dfa0: 007f9225 007ba664 00bf 2fff [ 83.406890] dfc0: 00ff2f2f 00ff 00ff 00ff 00ff 00ff 00799225 [ 83.415435] dfe0: 00ff be9f8780 00ff 4027e084 2010 [ 83.423980] Code: bad PC value [ 83.427490] ---[ end trace 4ae88755f08e391e ]--- [ 83.434570] S98configure[58]: Segmentation fault [ 83.840148] S98configure[58]: Segmentation fault [ 83.867004] S98configure[58]: gtk-update-icon-cache: Failed to open file /usr/share/icons/gnome/.icon-theme.cache : File exists [ 89.605407] S98configure[58]: gtk-update-icon-cache: Failed to open file /usr/share/icons/HighContrastLargePrint/.icon-theme.cache : File exists [ 89.932525] S98configure[58]: gtk-update-icon-cache: Failed to open file /usr/share/icons/Mist/.icon-theme.cache : File exists [ 89.967773] S98configure[58]: gtk-update-icon-cache: Failed to open file /usr/share/icons/gnome/.icon-theme.cache : File exists [ 91.477386] S98configure[58]: gtk-update-icon-cache: Failed to open file /usr/share/icons/HighContrastLargePrint/.icon-theme.cache : File exists [ 91.788269] S98configure[58]: gtk-update-icon-cache: Failed to open file /usr/share/icons/Mist/.icon-theme.cache : File exists [ 91.822631] S98configure[58]: gtk-update-icon-cache: Failed to open file /usr/share/icons/gnome/.icon-theme.cache : File exists [ 94.313598] S98configure[58]: gtk-update-icon-cache: Failed to open file /usr/share/icons/HighContrastLargePrint/.icon-theme.cache : File exists [ 95.381011] S98configure[58]: gtk-update-icon-cache: Failed to open file /usr/share/icons/Mist/.icon-theme.cache : File exists [ 95.415405] S98configure[58]: gtk-update-icon-cache: Failed to open file /usr/share/icons/gnome/.icon-theme.cache : File exists [ 99.084899] Unable to handle kernel NULL pointer dereference at virtual address [ 99.093383] pgd = c0004000 [ 99.096191] [] *pgd= [ 99.099945] Internal error: Oops: 17 [#2] [ 99.104125] Modules linked in: ipv6 [ 99.107788] CPU: 0 Tainted: G D (3.0.0+ #1) [ 99.113342] PC is at ehci_quiesce+0xc/0x94 [ 99.117614] LR is at ehci_stop+0x34/0x8c [ 99.121734] pc : [c0325ce4] lr : [c0328bfc] psr: 21d3 [ 99.121734] sp : c064de70 ip : 0108 fp : c06b8624 [ 99.133728] r10: c064dec0 r9 : r8 : dee08504 [ 99.139190] r7 : c0328b94 r6 : 0100 r5 : dee08504 r4 : dee08608 [ 99.145996] r3 : r2 : dee086ec r1 : dee086b8 r0 : dee08608 [ 99.152832] Flags: nzCv IRQs off FIQs off Mode SVC_32 ISA ARM Segment kernel [ 99.160644] Control: 10c5387d Table: 9d804019 DAC: 0015 [ 99.166656] Process swapper (pid: 0, stack limit = 0xc064c2f0) [ 99.172760] Stack: (0xc064de70 to 0xc064e000) [ 99.177307] de60: dee08608 dee086b8 dee08608 dee08504 [ 99.185852] de80: 0100 c0328bfc 0001 a153 dee08504 c007a3d4 00200200 6153 [ 99.194396] dea0: dee08504 c007a3d4 00200200 c06b87a0 c064c000 c007a3d4 c064c000 0003 [ 99.202941] dec0: c064dec0 c064dec0 000a 0001 c06b8628 c064c000 0100 c06b8600 [ 99.211517] dee0: 000a c0075ec0 a246 c0677bdc 0001 0003 0025 [ 99.220062] df00: c0654258 0003 0003 413fc082 c0076290 [ 99.228607] df20: 0025 c0040064 6053 fa20 c0044ff8 00051f4d [ 99.237152] df40: 00051f4d c06a662c c0654258 c0654258 0003 0003 413fc082 [ 99.245697] df60: c064df80 c0054dcc c0054dd8 6053 [ 99.254272] df80: 00051f4d 0063 04aae30b 0063 04a5c3be 0001 [ 99.262817] dfa0: c0654248 c0654258 c06d7a6c c0377404 c064c000 c0652254 c06a5d04 c065224c [ 99.271362] dfc0: 80004059 c0045f40 c064e9b4 c003341c c0ae1140 c0008868 c00082c8 060a [ 99.279907] dfe0: 8100 c003341c 10c53c7d c064e060 c0033418 8000803c [ 99.288482] [c0325ce4] (ehci_quiesce+0xc/0x94) from [c0328bfc] (ehci_stop+0x34/0x8c) [ 99.296936] [c0328bfc] (ehci_stop+0x34/0x8c) from [c007a3d4] (run_timer_softirq+0x15c/0x1f8) [ 99.306121] [c007a3d4] (run_timer_softirq+0x15c/0x1f8) from [c064dec0] (0xc064dec0) [ 99.314483] Code: c05d7f9a e92d4073
Re: [PATCH v6] OMAP3: beagle: add support for beagleboard xM revision C
On Fri, Jun 3, 2011 at 5:56 PM, Fernandes, Joel A joelag...@ti.com wrote:
The USB enable GPIO has been in beagleboard xM revision C
The USER button has been moved since beagleboard xM
Also, board specific initialization has been moved to beagle_config struct
and initialized in omap3_beagle_init_rev. Default values in struct are for
xMC.
Signed-off-by: Joel A Fernandes joelag...@ti.com
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
arch/arm/mach-omap2/board-omap3beagle.c | 70
---
1 files changed, 46 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 7f21d24..261fb53 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -61,7 +61,8 @@
* AXBX = GPIO173, GPIO172, GPIO171: 1 1 1
* C1_3 = GPIO173, GPIO172, GPIO171: 1 1 0
* C4 = GPIO173, GPIO172, GPIO171: 1 0 1
- * XM = GPIO173, GPIO172, GPIO171: 0 0 0
+ * XMA/XMB = GPIO173, GPIO172, GPIO171: 0 0 0
+ * XMC = GPIO173, GPIO172, GPIO171: 0 1 0
*/
enum {
OMAP3BEAGLE_BOARD_UNKN = 0,
@@ -69,14 +70,26 @@ enum {
OMAP3BEAGLE_BOARD_C1_3,
OMAP3BEAGLE_BOARD_C4,
OMAP3BEAGLE_BOARD_XM,
+ OMAP3BEAGLE_BOARD_XMC,
};
static u8 omap3_beagle_version;
-static u8 omap3_beagle_get_rev(void)
-{
- return omap3_beagle_version;
-}
+/*
+ * Board-specific configuration
+ * Defaults to BeagleBoard-xMC
+ */
+static struct {
+ int mmc1_gpio_wp;
+ int usb_pwr_level;
+ int reset_gpio;
+ int usr_button_gpio;
+} beagle_config = {
+ .mmc1_gpio_wp = -EINVAL,
+ .usb_pwr_level = GPIOF_OUT_INIT_LOW,
+ .reset_gpio = 129,
+ .usr_button_gpio = 4,
+};
static struct gpio omap3_beagle_rev_gpios[] __initdata = {
{ 171, GPIOF_IN, rev_id_0 },
@@ -111,18 +124,32 @@ static void __init omap3_beagle_init_rev(void)
case 7:
printk(KERN_INFO OMAP3 Beagle Rev: Ax/Bx\n);
omap3_beagle_version = OMAP3BEAGLE_BOARD_AXBX;
+ beagle_config.mmc1_gpio_wp = 29;
+ beagle_config.reset_gpio = 170;
+ beagle_config.usr_button_gpio = 7;
break;
case 6:
printk(KERN_INFO OMAP3 Beagle Rev: C1/C2/C3\n);
omap3_beagle_version = OMAP3BEAGLE_BOARD_C1_3;
+ beagle_config.mmc1_gpio_wp = 23;
+ beagle_config.reset_gpio = 170;
+ beagle_config.usr_button_gpio = 7;
break;
case 5:
printk(KERN_INFO OMAP3 Beagle Rev: C4\n);
omap3_beagle_version = OMAP3BEAGLE_BOARD_C4;
+ beagle_config.mmc1_gpio_wp = 23;
+ beagle_config.reset_gpio = 170;
+ beagle_config.usr_button_gpio = 7;
break;
case 0:
printk(KERN_INFO OMAP3 Beagle Rev: xM\n);
Since it sounds like there is already another revision coming, update
the text above to:
printk(KERN_INFO OMAP3 Beagle Rev: xM Ax/Bx\n);
omap3_beagle_version = OMAP3BEAGLE_BOARD_XM;
+ beagle_config.usb_pwr_level = GPIOF_OUT_INIT_HIGH;
+ break;
+ case 2:
+ printk(KERN_INFO OMAP3 Beagle Rev: xM C\n);
+ omap3_beagle_version = OMAP3BEAGLE_BOARD_XMC;
break;
default:
printk(KERN_INFO OMAP3 Beagle Rev: unknown %hd\n,
beagle_rev);
@@ -234,7 +261,7 @@ static struct omap2_hsmmc_info mmc[] = {
{
.mmc = 1,
.caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
- .gpio_wp = 29,
+ .gpio_wp = -EINVAL,
},
{} /* Terminator */
};
@@ -252,17 +279,11 @@ static struct gpio_led gpio_leds[];
static int beagle_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
- int r, usb_pwr_level;
-
- if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
- mmc[0].gpio_wp = -EINVAL;
- } else if ((omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_C1_3) ||
- (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_C4)) {
- omap_mux_init_gpio(23, OMAP_PIN_INPUT);
- mmc[0].gpio_wp = 23;
- } else {
- omap_mux_init_gpio(29, OMAP_PIN_INPUT);
- }
+ int r;
+
+ if (beagle_config.mmc1_gpio_wp != -EINVAL)
+ omap_mux_init_gpio(beagle_config.mmc1_gpio_wp,
OMAP_PIN_INPUT);
+ mmc[0].gpio_wp = beagle_config.mmc1_gpio_wp;
/* gpio + 0 is mmc0_cd (input/IRQ) */
mmc[0].gpio_cd = gpio + 0;
omap2_hsmmc_init(mmc);
@@ -276,9 +297,7 @@ static int beagle_twl_gpio_setup(struct device *dev,
* high / others active low)
* DVI reset GPIO is
Re: [PATCH v6] OMAP3: beagle: add support for beagleboard xM revision C
On Sat, Jun 4, 2011 at 4:01 AM, Kooi, Koen k-k...@ti.com wrote:
Texas Instruments Limited, 800 Pavilion Drive, Northampton, NN4 7YL.
Registered in England Wales under company number 00574102
From: Fernandes, Joel A
Sent: 03 June 2011 23:56
To: linux-omap@vger.kernel.org
Cc: bea...@list.ti.com - Ultra-low cost OMAP3 board (May contain non-TIers);
beaglebo...@googlegroups.com; Maupin, Chase
Subject: [beagle] [PATCH v6] OMAP3: beagle: add support for beagleboard xM
revision C
The USB enable GPIO has been in beagleboard xM revision C
The USER button has been moved since beagleboard xM
Also, board specific initialization has been moved to beagle_config struct
and initialized in omap3_beagle_init_rev. Default values in struct are for
xMC.
Signed-off-by: Joel A Fernandes joelag...@ti.com
Signed-off-by: Koen Kooi k...@dominion.thruhere.net
---
arch/arm/mach-omap2/board-omap3beagle.c | 70
---
1 files changed, 46 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c
b/arch/arm/mach-omap2/board-omap3beagle.c
index 7f21d24..261fb53 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -276,9 +297,7 @@ static int beagle_twl_gpio_setup(struct device *dev,
* high / others active low)
* DVI reset GPIO is different between beagle revisions
*/
- if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
- usb_pwr_level = GPIOF_OUT_INIT_HIGH;
- beagle_dvi_device.reset_gpio = 129;
+ if (cpu_is_omap3630()) {
PLease add a comment like valid for all xM versions to the above.
@@ -526,7 +545,7 @@ static void __init beagle_opp_init(void)
}
/* Custom OPP enabled for XM */
- if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
+ if (cpu_is_omap3630()) {
same
@@ -566,6 +585,9 @@ static void __init omap3_beagle_init(void)
omap3_mux_init(board_mux, OMAP_PACKAGE_CBB);
omap3_beagle_init_rev();
omap3_beagle_i2c_init();
+
+ gpio_buttons[0].gpio = beagle_config.usr_button_gpio;
+
And please move that into
static struct gpio_keys_button gpio_buttons[] = {
{
.code = BTN_EXTRA,
.gpio = 7, - there
I don't follow. The other assignment is dynamic, following the
detection of the board revision and, hopefully, before the
initialization of the GPIO button. I don't see how it can be moved
here. Perhaps it might be better to set it to -EINVAL to indicate it
will be assigned later?
.desc = user,
.wakeup = 1,
},
}
regards,
Koen
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/2] OMAP2+: PANDA: Fix up random or missing MAC addresses for eth0 and wlan0
On Fri, Mar 25, 2011 at 4:23 PM, Nicolas Pitre nicolas.pi...@linaro.org wrote: On Fri, 25 Mar 2011, Jason Kridner wrote: I very much like this approach. I believed the ability to use the die ID to get a unique code was reasonable approach and that is why I didn't get an EEPROM put onto the BeagleBoard, though Gerald is looking at adding one on a future revision because the lack of one wasn't well received. Minor questions below. If this code had been available and/or the procedure well documented before then I believe the reception would have been better. Understood. Live and learn and try not to repeat the same mistakes. Hopefully others pick up on this one. The use of the OMAP die id below makes this OMAP specific and the list referenced below of the devices to be referenced makes it Panda specific. Is there a way to make the list board specific, but to make these functions that will be used across many OMAP platforms reusable? I believe that this current code will result in a lot of cut-and-paste. My preference is that this is accepted and that we make this more general when we add this to other OMAP platforms, but it'd be great to capture your suggestions on how to do so before those cut-and-paste patch sets start coming in. It is true that this might get copied. But as I suggested to Andy, it is best to wait and see how often this happens before generalizing the approach. Consolidation is easier when you can see what is actually common and what is board specific. Otherwise it is easy to fall into the over-engineering trap. Makes sense. I hope to see this patch accepted for Panda quickly and we can follow Andy's advice on how to make it more general in the future as we wee how people use/need it. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/2] OMAP2+: PANDA: Fix up random or missing MAC addresses for eth0 and wlan0
On Fri, Mar 25, 2011 at 3:39 AM, Hema Kalliguddi hem...@ti.com wrote:
Hi,
one Minor comment.
-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Andy Green
Sent: Friday, March 25, 2011 2:58 AM
To: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org
Cc: patc...@linaro.org; nicolas.pi...@linaro.org;
a...@arndb.de; x0132...@ti.com; s-...@ti.com;
t...@atomide.com; Alan Cox; Andy Green
Subject: [RFC PATCH 2/2] OMAP2+: PANDA: Fix up random or
missing MAC addresses for eth0 and wlan0
This patch registers a network device notifier callback to set the mac
addresses for the onboard network assets of Panda correctly,
despite the
drivers involved have used a random or all-zeros MAC address.
The technique was suggested by Alan Cox on lkml.
It works by device path so it corrects the MAC addresses even if the
drivers are in modules loaded in an order that changes their interface
name from usual (eg, the onboard module might be wlan1 if there is a
USB wireless stick plugged in and its module is inserted first.)
Cc: Alan Cox a...@lxorguk.ukuu.org.uk
Signed-off-by: Andy Green andy.gr...@linaro.org
I very much like this approach. I believed the ability to use the die
ID to get a unique code was reasonable approach and that is why I
didn't get an EEPROM put onto the BeagleBoard, though Gerald is
looking at adding one on a future revision because the lack of one
wasn't well received. Minor questions below.
---
arch/arm/mach-omap2/board-omap4panda.c | 91
1 files changed, 91 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c
b/arch/arm/mach-omap2/board-omap4panda.c
index 80b8860..0b92873 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -28,9 +28,12 @@
#include linux/regulator/machine.h
#include linux/regulator/fixed.h
#include linux/wl12xx.h
+#include linux/netdevice.h
+#include linux/if_ether.h
#include mach/hardware.h
#include mach/omap4-common.h
+#include mach/id.h
#include asm/mach-types.h
#include asm/mach/arch.h
#include asm/mach/map.h
@@ -506,6 +509,92 @@ static inline void board_serial_init(void)
}
#endif
+/*
+ * These device paths represent the onboard USB - Ethernet
bridge, and
+ * the WLAN module on Panda, both of which need their random
or all-zeros
+ * mac address replacing with a per-cpu stable generated one
+ */
+
+static const char * const panda_fixup_mac_device_paths[] = {
+ usb1/1-1/1-1.1/1-1.1:1.0,
+ mmc1:0001:2,
+};
+
+static int panda_device_path_need_mac(struct device *dev)
+{
+ const char **try = panda_fixup_mac_device_paths;
+ const char *path;
+ int count = ARRAY_SIZE(panda_fixup_mac_device_paths);
+ const char *p;
+ int len;
+ struct device *devn;
+
+ while (count--) {
+
+ p = *try + strlen(*try);
+ devn = dev;
+
+ while (devn) {
+
+ path = dev_name(devn);
+ len = strlen(path);
+
+ if ((p - *try) len) {
+ devn = NULL;
+ continue;
+ }
+
+ p -= len;
+
+ if (strncmp(path, p, len)) {
+ devn = NULL;
+ continue;
+ }
+
+ devn = devn-parent;
+ if (p == *try)
+ return count;
+
+ if (devn != NULL (p - *try) 2)
+ devn = NULL;
+
+ p--;
+ if (devn != NULL *p != '/')
+ devn = NULL;
+ }
+
+ try++;
+ }
+
+ return -ENOENT;
+}
+
+static int omap_panda_netdev_event(struct notifier_block *this,
+ unsigned long
The use of the OMAP die id below makes this OMAP specific and the list
referenced below of the devices to be referenced makes it Panda
specific. Is there a way to make the list board specific, but to make
these functions that will be used across many OMAP platforms reusable?
I believe that this current code will result in a lot of
cut-and-paste. My preference is that this is accepted and that we
make this more general when we add this to other OMAP platforms, but
it'd be great to capture your suggestions on how to do so before those
cut-and-paste patch sets start coming in.
event, void *ptr)
+{
+ struct net_device *dev = ptr;
+ struct sockaddr sa;
+ int n;
+
+ if (event != NETDEV_REGISTER)
+ return NOTIFY_DONE;
+
+ n = panda_device_path_need_mac(dev-dev.parent);
+ if (n = 0) {
+ sa.sa_family = dev-type;
+ omap2_die_id_to_ethernet_mac(sa.sa_data, n);
+ dev-netdev_ops-ndo_set_mac_address(dev, sa);
Re: leds-gpio broken with current git?
On Feb 23, 2009, at 4:08 PM, David Brownell wrote:
On Monday 23 February 2009, David Brownell wrote:
Perhaps something broke with Tony's RC1 merge?
The LEDs are broken for me as well.
Still works for me. Did you maybe not enable the twl4030
GPIO support in Kconfig?
Oh, and if you did *not*, please give this patch a try.
I've been meaning to test it.
Thanks, the patch works. Not enabling the TWL4030 GPIO was the issue
and this patch provides a good method of not having all the GPIOs fail
due to the failure of just one. Diego assisted in the test, as I had
first taken the approach of removing the failing GPIO.
- Dave
==
Sometimes it's awkward to make sure that the array in the
platform_data handed to the leds-gpio driver has only valid
data ... some leds may not be always available, and coping
with that currently requires patching or rebuilding the array.
This patch fixes that by making it be OK to pass an invalid
GPIO (such as -EINVAL) ... such table entries are skipped.
---
drivers/leds/leds-gpio.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
--- a/drivers/leds/leds-gpio.c
+++ b/drivers/leds/leds-gpio.c
@@ -90,13 +90,19 @@ static int gpio_led_probe(struct platfor
cur_led = pdata-leds[i];
led_dat = leds_data[i];
+ /* skip leds that aren't available */
+ led_dat-gpio = cur_led-gpio;
+ if (!gpio_is_valid(led_dat-gpio)) {
+ dev_dbg(pdev-dev, skipping %s\n, cur_led-name);
+ continue;
+ }
+
ret = gpio_request(cur_led-gpio, cur_led-name);
if (ret 0)
goto err;
led_dat-cdev.name = cur_led-name;
led_dat-cdev.default_trigger = cur_led-default_trigger;
- led_dat-gpio = cur_led-gpio;
led_dat-can_sleep = gpio_cansleep(cur_led-gpio);
led_dat-active_low = cur_led-active_low;
if (pdata-gpio_blink_set) {
@@ -125,6 +131,8 @@ static int gpio_led_probe(struct platfor
err:
if (i 0) {
for (i = i - 1; i = 0; i--) {
+ if (!gpio_is_valid(leds_data[i].gpio))
+ continue;
led_classdev_unregister(leds_data[i].cdev);
cancel_work_sync(leds_data[i].work);
gpio_free(leds_data[i].gpio);
@@ -145,6 +153,8 @@ static int __devexit gpio_led_remove(str
leds_data = platform_get_drvdata(pdev);
for (i = 0; i pdata-num_leds; i++) {
+ if (!gpio_is_valid(leds_data[i].gpio))
+ continue;
led_classdev_unregister(leds_data[i].cdev);
cancel_work_sync(leds_data[i].work);
gpio_free(leds_data[i].gpio);
--
To unsubscribe from this list: send the line unsubscribe linux-
omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP: board-omap3beagle: set i2c-3 to 100kHz
On Jan 23, 2009, at 4:48 AM, Koen Kooi wrote: Op 23 jan 2009, om 10:52 heeft David Brownell het volgende geschreven: On Friday 23 January 2009, Koen Kooi wrote: Op 15 jan 2009, om 20:30 heeft Koen Kooi het volgende geschreven: From: Koen Kooi k...@beagleboard.org Changing it to 100kHz is needed to make more devices works properly. Controlling the TI DLP Pico projector[1] doesn't work properly at 400kHz, 100kHz and lower work fine. EDID readout is unaffected by this change. [1] http://focus.ti.com/dlpdmd/docs/dlpdiscovery.tsp?sectionId=60tabId=2234 Signed-off-by: Koen Kooi k...@beagleboard.org Any comments on this patch? I2C-3 is only used for talking on DVI, right? Which means EDID ... and maybe DLP/Pico, unless someone uses it as an I2C adapter. (Which some folk hack together on PCs...) Seems harmless to me, but I'd add a comment explaining why just 100 MHz. (The Pico manual says 400 KHz should work.) The updated manual will say 400kHz won't work, the TI DLP engineers were the ones that designed the pico that pointed the i2c speed problem out to me :) I'd be happy to change the patch if needed, but I think the updated manual will take care of most issues. regards, Koen Given that this port is only used on the DVI port for the BeagleBoard, I believe it is appropriate to set it to 100kHz as Koen has done. - Dave regards, Koen --- arch/arm/mach-omap2/board-omap3beagle.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/ mach- omap2/board-omap3beagle.c index fe97bab..f279404 100644 --- a/arch/arm/mach-omap2/board-omap3beagle.c +++ b/arch/arm/mach-omap2/board-omap3beagle.c @@ -227,7 +227,7 @@ static int __init omap3_beagle_i2c_init(void) #ifdef CONFIG_I2C2_OMAP_BEAGLE omap_register_i2c_bus(2, 400, NULL, 0); #endif - omap_register_i2c_bus(3, 400, NULL, 0); + omap_register_i2c_bus(3, 100, NULL, 0); return 0; } -- 1.5.6.3 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
