Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
Hi Felibe, On Nov 1, 2012, at 12:14 AM, Felipe Balbi wrote: Hi, On Wed, Oct 31, 2012 at 11:36:25PM +0200, Pantelis Antoniou wrote: * Pantelis Antoniou pa...@antoniou-consulting.com [121031 13:14]: On Oct 31, 2012, at 9:55 PM, Benoit Cousson wrote: Yeah, I do agree. I'm confused as well. Only OMAP IPs under PRCM control could have an hwmod and thus must be handled by an omap_device. Any devices that is created later cannot be omap_device. The DT core will create regular platform_device for them. Since cape is an external board, it should have nothing to do with omap_device. Looking at your patch: da8xx-dt: Create da8xx DT adapter device I understand why you do that, but in fact that patch does not make sense to me :-( Why do you have to create an omap_device from the driver probe? The problem is that capes are not external boards in the normal sense as a PCI board is. In the PCI case the hardware that implements the desired functionality is on the PCI board, while in the cape case the hardware module is in the SoC. The cape most of the times is quite simple and contains passive components, leds or some kind of I2C/SPI devices. Ah now I see, you're talking about the beaglebone extension boards :) The way to deal with those properly is to just edit the board .dts entry to include omap-beaglebone-cape-xyz.dtsi whatever. That is what is being done... This is the fallout. You can't instantiate the omap_device early in the boot process like it was done up to now in the board file. You can only do that later in the boot process (for built-in cape drivers), or even after user-space has booted and the matching cape driver module has been loaded. Yes you can, just edit the .dts file for the extension board you have connected. This stuff should be DT only for sure, let's not even start adding platform_data entries for that. The omap_device entries for the omap internal devices will be created automatically during startup based on the .dts. Note that you can set status = disabled for the omap internal devices in the .dts file, the devices are there in the hardware. If you are sure the extension boards are safely hot pluggable, then all you need is some interface to enable and disable devices after booting. But that should be done in Linux generic way. So we should not export any omap_hwmod or omap_device things, and want to keep it __init only, and local to arch/arm/mach-omap2. I disagree. This is not something that is handled by just editing the dts. The way it is handled, is in the Linux generic way, we have a proper bus, and the drivers as compiled as standalone file. when you have an actual bus, that'd be correct. What do you think capebus is? It is an actual bus that allows you to do so. We're hitting a use case that wasn't there in omap until now. There a a whole bunch of conflicting capes. There's no way to instantiate them together. They must be instantiated only after their EEPROMs are read and they are matched to their corresponding cape drivers. why this requirement of instantiating them only after reading EEPROMs ? It's unnecessary to add that requirement, just do what Tony said (include my-awesome-cape.dtsi to bone.dts) and all i2c/spi devices should be created automatically. The thing is that there is no such thing as a cape-device. The cape is just a collection of I2C, 1-wire and SPI devices anyway. What we should instantiate is bmp085, tls2550, sht21, instead of instantiating beagle-bone-weather-cape. What's the problem in just instantiating all of those from bone.dts ? Expose the EEPROMs to userland so whatever SW you guys have running on the bone can figure out what features to expose to the SDK which the user sees, but the kernel doesn't need to know that there is a weather-cape attached to the bone. The I2C/SPI devices are not a problem at all. Let me try to explain what the problem is, and why it all this is needed. First of all, capes may be relatively simple boards, which may function as a generic device - like the generic capes. They might not necessarily be simple. Some capes, for example the geiger cape have a number of components that perform a specific task; in this instance the driving circuit of the geiger tube and the event detector input. Other capes that are being designed now are even more complex, i.e. there's a radar cape, an fpga cape and so on. So for these kind of boards you will need a specific driver. That driver will probably use some generic-cape bits (like gpios, pwms, keys what-ever). But it will put them to use in the custom in-kernel driver in it's own way. You can't put that task to user-space, if it's ever slightly complex. So for really simple capes, after considerable pain you might, just might, dump the problem to user-space and try to make it work. People have tried that and it's a total pain. There is no way that
Re: [PATCH 4/4] arm/dts: am33xx: Add CPSW and MDIO module nodes for AM33XX
On Wed, Oct 31, 2012 at 04:17:27PM +0100, Benoit Cousson wrote: + compatible = ti,cpsw; + ti,hwmods = cpgmac0; + cpdma_channels = 8; + host_port_no = 0; + cpdma_reg_ofs = 0x800; + cpdma_sram_ofs = 0xa00; + ale_reg_ofs = 0xd00; + ale_entries = 1024; + host_port_reg_ofs = 0x108; + hw_stats_reg_ofs = 0x900; + bd_ram_ofs = 0x2000; + bd_ram_size = 0x2000; + no_bd_ram = 0; + rx_descs = 64; + mac_control = 0x20; Do you have to store all these data in the DTS? Cannot it be in the driver? Do you expect to have several instance of the same IP with different parameters here? As I understand it, there are only two different layouts for the CPSW, the one in the dm814x and the one in the am335x. So I think it would work to put only the version register offet in the DT, and the let the driver figure out the rest from there. But if TI is planning on reordering the registers with each new silicon revision, again and again, then it might make sense to keep the offsets in the DT. [ I really wonder why the hardware people think that reshuffling the register layout constitutes an improvement. ] Thanks, Richard -- 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: OMAP baseline test results for v3.7-rc1
Hi Paul, On Wed, Oct 31, 2012 at 10:44 PM, Paul Walmsley p...@pwsan.com wrote: Hi On Wed, 31 Oct 2012, Jean Pihet wrote: Paul, Could you please check with the 2 calls to PM QoS from the I2C code commented out? This will rule out the PM QoS impact. Will be happy to do a test run for you, after the boot log from your local test run is posted: http://marc.info/?l=linux-arm-kernelm=135167153510814w=2 As said earlier [1] the test has been done already. I did check the boot messages and tried to read/write the RTC. All test were successfull and the only difference in the logs was the absence of the I2C timeout messages. I can redo the tests and provide a log but that will not happen before Saturday. [1] http://marc.info/?l=linux-omapm=135161909714517w=2 Regards, Jean - Paul -- 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: [RESEND PATCH 05/11] ARM: OMAP: USB: Host: usb host Device tree node Adaptation
From: Tony Lindgren [t...@atomide.com]
Sent: Wednesday, October 31, 2012 11:59 PM
To: Munegowda, Keshava
Cc: linux-omap@vger.kernel.org; devicetree-disc...@lists.ozlabs.org;
linux-...@vger.kernel.org; linux-...@vger.kernel.org; Balbi, Felipe;
sa...@linux.intel.com; Cousson, Benoit
Subject: Re: [RESEND PATCH 05/11] ARM: OMAP: USB: Host: usb host Device tree
node Adaptation
* Keshava Munegowda keshava_mgo...@ti.com [121031 07:29]:
The USB2 Host device node is extracted and used in the probe
of the driver to initialize the usb ports and controller. The
platform specific initialization is also performed.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/usb-host.c |2 -
drivers/mfd/omap-usb-host.c| 163
+++-
include/linux/platform_data/usb-omap.h | 19 +++-
3 files changed, 133 insertions(+), 51 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index d1dbe12..239c175 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -502,8 +502,6 @@ void __init usbhs_init(const struct usbhs_omap_board_data
*pdata)
}
ehci_data.phy_reset = pdata-phy_reset;
ohci_data.es2_compatibility = pdata-es2_compatibility;
- usbhs_data.ehci_data = ehci_data;
- usbhs_data.ohci_data = ohci_data;
if (cpu_is_omap34xx()) {
setup_ehci_io_mux(pdata-port_mode);
Just checking.. Have you tested that these patches also
still work without device tree?
Regards,
Tony
No ! with out device tree enabled , these patches does not work.
do I need to make a code such way that it works with and without
device tree..?
regards
keshava
--
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
Fwd: [PATCHv2] Input: omap4-keypad: Add pinctrl support
On Wed, Oct 31, 2012 at 9:10 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Linus Walleij linus.wall...@linaro.org writes: piece of hardware, this would be the right thing to do, and I think the in-kernel examples are all simple, e.g. arch/arm/mach-omap2/powerdomain* is all about power domains and nothing else, FYI... that code isn't the same as PM domain. This sort of points to a core problem here. Our terminologies are ambiguous that we cannot understand each others code. As long as linux/pm_domain.h begins: /* * pm_domain.h - Definitions and headers related to device power domains. * But arguably that should just be patched (I think there are a few remnants in the code still implying that these things are only about power). That code is for the *hardware* powerdomains, not the software concept of PM domain. In OMAP, PM domain is implmented at the omap_device level. And omap_device is the abstraction of an IP block that knows about all the PM related register settings, clocks, HW powerdomain, voltage domain, PM related pin-muxing etc. etc.All of these things are abstracted in an omap_device, so that the PM domain implementation for OMAP looks rather simple (c.f. omap_device_pm_domain in arch/arm/plat-omap/omap_device.c.) OK following now... I think the lesser of two evils is the distributed approach, The pinctrl examples I've seen mentioned so far are all PM related (sleep, idle, wakeup, etc.) so to me I think they still belong in PM domains (and that's how we handle the PM related pins in OMAP.) Well, the pinctrl grabbers in these drivers are using these states also for platforms that do not even select CONFIG_PM. For example mach-nomadik is quite happy that the PL011 driver is thusly muxing in its pins. And would require refactoring to use PM domains. So basically this requirement comes down to: - When dealing with a SoC IP block driver - That need to multiplex pins - Then your SoC must select CONFIG_PM and CONFIG_PM_RUNTIME and CONFIG_PM_GENERIC_DOMAINS and implement proper domain handling hooks. Is this correct? And for Mark, Dmitry, does this correspond to your view? It's actually something that needs to be acknowledged by the ARM SoC maintainers, because they will be the ones telling all subarch maintainers to go implement full PM handling with these three frameworks whenever an SoC driver want to handle pins. Bascially all subsystem maintainers dealing with embedded SoCs need to be aligned on this as well... And IIUC not only pins but also silicon block clocks? I can surely fix these for my systems, but it really needs to be enforced widely or it will be a mess. I worry that the per-SoC power domain implementation which will live in arch/arm/mach-* as of today will become the new board file problem, overburdening the arch/* tree. Maybe I'm mistaken as to the size of these things, but just doing ls arch/arm/mach-omap2/powerdomain* makes me start worrying. Yes, I agree that this means more code/data in arch/arm/mach-*, but IMO, that's really where it belongs. It really is SoC integration details, and driver should really not know about it. OK we need feedback from ARM SoC on this. Yours, Linus Walleij -- 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 4/4] arm/dts: am33xx: Add CPSW and MDIO module nodes for AM33XX
On 11/1/2012 8:45 AM, Richard Cochran wrote: On Wed, Oct 31, 2012 at 04:17:27PM +0100, Benoit Cousson wrote: + compatible = ti,cpsw; + ti,hwmods = cpgmac0; + cpdma_channels = 8; + host_port_no = 0; + cpdma_reg_ofs = 0x800; + cpdma_sram_ofs = 0xa00; + ale_reg_ofs = 0xd00; + ale_entries = 1024; + host_port_reg_ofs = 0x108; + hw_stats_reg_ofs = 0x900; + bd_ram_ofs = 0x2000; + bd_ram_size = 0x2000; + no_bd_ram = 0; + rx_descs = 64; + mac_control = 0x20; Do you have to store all these data in the DTS? Cannot it be in the driver? Do you expect to have several instance of the same IP with different parameters here? As I understand it, there are only two different layouts for the CPSW, the one in the dm814x and the one in the am335x. So I think it would work to put only the version register offet in the DT, and the let the driver figure out the rest from there. Yes, that's indeed better. We did that for other IPs already (GPIO, I2C...) But if TI is planning on reordering the registers with each new silicon revision, again and again, then it might make sense to keep the offsets in the DT. Yeah, let's assume they will do a better job in the future. All these offset registers information does belong to the driver, and even if the HW change a lot, I still rather hide that in the driver. It will always be cleaner, most efficient, and will reduce the size if the blob. [ I really wonder why the hardware people think that reshuffling the register layout constitutes an improvement. ] I've been wondering that for ten years :-( I'm always hoping it will be better some day. Regards, Benoit -- 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 11/1/2012 8:02 AM, Pantelis Antoniou wrote: Hi Felibe, On Nov 1, 2012, at 12:14 AM, Felipe Balbi wrote: Hi, On Wed, Oct 31, 2012 at 11:36:25PM +0200, Pantelis Antoniou wrote: * Pantelis Antoniou pa...@antoniou-consulting.com [121031 13:14]: On Oct 31, 2012, at 9:55 PM, Benoit Cousson wrote: Yeah, I do agree. I'm confused as well. Only OMAP IPs under PRCM control could have an hwmod and thus must be handled by an omap_device. Any devices that is created later cannot be omap_device. The DT core will create regular platform_device for them. Since cape is an external board, it should have nothing to do with omap_device. Looking at your patch: da8xx-dt: Create da8xx DT adapter device I understand why you do that, but in fact that patch does not make sense to me :-( Why do you have to create an omap_device from the driver probe? The problem is that capes are not external boards in the normal sense as a PCI board is. In the PCI case the hardware that implements the desired functionality is on the PCI board, while in the cape case the hardware module is in the SoC. The cape most of the times is quite simple and contains passive components, leds or some kind of I2C/SPI devices. Ah now I see, you're talking about the beaglebone extension boards :) The way to deal with those properly is to just edit the board .dts entry to include omap-beaglebone-cape-xyz.dtsi whatever. That is what is being done... This is the fallout. You can't instantiate the omap_device early in the boot process like it was done up to now in the board file. You can only do that later in the boot process (for built-in cape drivers), or even after user-space has booted and the matching cape driver module has been loaded. Yes you can, just edit the .dts file for the extension board you have connected. This stuff should be DT only for sure, let's not even start adding platform_data entries for that. The omap_device entries for the omap internal devices will be created automatically during startup based on the .dts. Note that you can set status = disabled for the omap internal devices in the .dts file, the devices are there in the hardware. If you are sure the extension boards are safely hot pluggable, then all you need is some interface to enable and disable devices after booting. But that should be done in Linux generic way. So we should not export any omap_hwmod or omap_device things, and want to keep it __init only, and local to arch/arm/mach-omap2. I disagree. This is not something that is handled by just editing the dts. The way it is handled, is in the Linux generic way, we have a proper bus, and the drivers as compiled as standalone file. when you have an actual bus, that'd be correct. What do you think capebus is? It is an actual bus that allows you to do so. We're hitting a use case that wasn't there in omap until now. There a a whole bunch of conflicting capes. There's no way to instantiate them together. They must be instantiated only after their EEPROMs are read and they are matched to their corresponding cape drivers. why this requirement of instantiating them only after reading EEPROMs ? It's unnecessary to add that requirement, just do what Tony said (include my-awesome-cape.dtsi to bone.dts) and all i2c/spi devices should be created automatically. The thing is that there is no such thing as a cape-device. The cape is just a collection of I2C, 1-wire and SPI devices anyway. What we should instantiate is bmp085, tls2550, sht21, instead of instantiating beagle-bone-weather-cape. What's the problem in just instantiating all of those from bone.dts ? Expose the EEPROMs to userland so whatever SW you guys have running on the bone can figure out what features to expose to the SDK which the user sees, but the kernel doesn't need to know that there is a weather-cape attached to the bone. The I2C/SPI devices are not a problem at all. Let me try to explain what the problem is, and why it all this is needed. First of all, capes may be relatively simple boards, which may function as a generic device - like the generic capes. They might not necessarily be simple. Some capes, for example the geiger cape have a number of components that perform a specific task; in this instance the driving circuit of the geiger tube and the event detector input. Other capes that are being designed now are even more complex, i.e. there's a radar cape, an fpga cape and so on. So for these kind of boards you will need a specific driver. That driver will probably use some generic-cape bits (like gpios, pwms, keys what-ever). But it will put them to use in the custom in-kernel driver in it's own way. You can't put that task to user-space, if it's ever slightly complex. So for really simple capes, after considerable pain you might, just might, dump the problem to user-space and try to make it work. People have tried that and it's a total pain. There is no way that this will work with anything more complex than a
[RFC PATCH] ARM: OMAP4: ID: Improve features detection and check
Replaces several flags bearing the same meaning. There is no need
to set flags due to different omap types here, it can be checked
in appropriate places as well.
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
arch/arm/mach-omap2/id.c | 25 +++--
arch/arm/mach-omap2/soc.h |8 ++--
2 files changed, 9 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index cf2362c..3c47a19 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -28,6 +28,9 @@
#include soc.h
#include control.h
+#define OMAP4_SILICON_TYPE_STANDARD0x01
+#define OMAP4_SILICON_TYPE_PERFORMANCE 0x02
+
static unsigned int omap_revision;
static const char *cpu_rev;
u32 omap_features;
@@ -273,25 +276,11 @@ void __init omap4xxx_check_features(void)
{
u32 si_type;
- if (cpu_is_omap443x())
- omap_features |= OMAP4_HAS_MPU_1GHZ;
-
+ si_type =
+ (read_tap_reg(OMAP4_CTRL_MODULE_CORE_STD_FUSE_PROD_ID_1) 16) 0x03;
- if (cpu_is_omap446x()) {
- si_type =
- read_tap_reg(OMAP4_CTRL_MODULE_CORE_STD_FUSE_PROD_ID_1);
- switch ((si_type (3 16)) 16) {
- case 2:
- /* High performance device */
- omap_features |= OMAP4_HAS_MPU_1_5GHZ;
- break;
- case 1:
- default:
- /* Standard device */
- omap_features |= OMAP4_HAS_MPU_1_2GHZ;
- break;
- }
- }
+ if (si_type == OMAP4_SILICON_TYPE_PERFORMANCE)
+ omap_features = OMAP4_HAS_PERF_SILICON;
}
void __init ti81xx_check_features(void)
diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h
index 0700964..f31d907 100644
--- a/arch/arm/mach-omap2/soc.h
+++ b/arch/arm/mach-omap2/soc.h
@@ -435,9 +435,7 @@ extern u32 omap_features;
#define OMAP3_HAS_IO_WAKEUPBIT(6)
#define OMAP3_HAS_SDRC BIT(7)
#define OMAP3_HAS_IO_CHAIN_CTRLBIT(8)
-#define OMAP4_HAS_MPU_1GHZ BIT(9)
-#define OMAP4_HAS_MPU_1_2GHZ BIT(10)
-#define OMAP4_HAS_MPU_1_5GHZ BIT(11)
+#define OMAP4_HAS_PERF_SILICON BIT(9)
#define OMAP3_HAS_FEATURE(feat,flag) \
@@ -465,9 +463,7 @@ static inline unsigned int omap4_has_ ##feat(void) \
return omap_features OMAP4_HAS_ ##flag; \
} \
-OMAP4_HAS_FEATURE(mpu_1ghz, MPU_1GHZ)
-OMAP4_HAS_FEATURE(mpu_1_2ghz, MPU_1_2GHZ)
-OMAP4_HAS_FEATURE(mpu_1_5ghz, MPU_1_5GHZ)
+OMAP4_HAS_FEATURE(perf_silicon, PERF_SILICON)
#endif /* __ASSEMBLY__ */
--
1.7.9.5
--
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: [RESEND PATCH 05/11] ARM: OMAP: USB: Host: usb host Device tree node Adaptation
On Thu, Nov 01, 2012 at 09:19:48AM +0100, Munegowda, Keshava wrote:
From: Tony Lindgren [t...@atomide.com]
Sent: Wednesday, October 31, 2012 11:59 PM
To: Munegowda, Keshava
Cc: linux-omap@vger.kernel.org; devicetree-disc...@lists.ozlabs.org;
linux-...@vger.kernel.org; linux-...@vger.kernel.org; Balbi, Felipe;
sa...@linux.intel.com; Cousson, Benoit
Subject: Re: [RESEND PATCH 05/11] ARM: OMAP: USB: Host: usb host Device tree
node Adaptation
* Keshava Munegowda keshava_mgo...@ti.com [121031 07:29]:
The USB2 Host device node is extracted and used in the probe
of the driver to initialize the usb ports and controller. The
platform specific initialization is also performed.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/usb-host.c |2 -
drivers/mfd/omap-usb-host.c| 163
+++-
include/linux/platform_data/usb-omap.h | 19 +++-
3 files changed, 133 insertions(+), 51 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index d1dbe12..239c175 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -502,8 +502,6 @@ void __init usbhs_init(const struct
usbhs_omap_board_data *pdata)
}
ehci_data.phy_reset = pdata-phy_reset;
ohci_data.es2_compatibility = pdata-es2_compatibility;
- usbhs_data.ehci_data = ehci_data;
- usbhs_data.ohci_data = ohci_data;
if (cpu_is_omap34xx()) {
setup_ehci_io_mux(pdata-port_mode);
Just checking.. Have you tested that these patches also
still work without device tree?
Regards,
Tony
No ! with out device tree enabled , these patches does not work.
do I need to make a code such way that it works with and without
device tree..?
yes. OMAP3/4 still have lots of legacy platform_data-only board support
;-)
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
Hi Benoit, On Nov 1, 2012, at 12:23 PM, Cousson, Benoit wrote: On 11/1/2012 8:02 AM, Pantelis Antoniou wrote: Hi Felibe, On Nov 1, 2012, at 12:14 AM, Felipe Balbi wrote: Hi, On Wed, Oct 31, 2012 at 11:36:25PM +0200, Pantelis Antoniou wrote: * Pantelis Antoniou pa...@antoniou-consulting.com [121031 13:14]: On Oct 31, 2012, at 9:55 PM, Benoit Cousson wrote: Yeah, I do agree. I'm confused as well. Only OMAP IPs under PRCM control could have an hwmod and thus must be handled by an omap_device. Any devices that is created later cannot be omap_device. The DT core will create regular platform_device for them. Since cape is an external board, it should have nothing to do with omap_device. Looking at your patch: da8xx-dt: Create da8xx DT adapter device I understand why you do that, but in fact that patch does not make sense to me :-( Why do you have to create an omap_device from the driver probe? The problem is that capes are not external boards in the normal sense as a PCI board is. In the PCI case the hardware that implements the desired functionality is on the PCI board, while in the cape case the hardware module is in the SoC. The cape most of the times is quite simple and contains passive components, leds or some kind of I2C/SPI devices. Ah now I see, you're talking about the beaglebone extension boards :) The way to deal with those properly is to just edit the board .dts entry to include omap-beaglebone-cape-xyz.dtsi whatever. That is what is being done... This is the fallout. You can't instantiate the omap_device early in the boot process like it was done up to now in the board file. You can only do that later in the boot process (for built-in cape drivers), or even after user-space has booted and the matching cape driver module has been loaded. Yes you can, just edit the .dts file for the extension board you have connected. This stuff should be DT only for sure, let's not even start adding platform_data entries for that. The omap_device entries for the omap internal devices will be created automatically during startup based on the .dts. Note that you can set status = disabled for the omap internal devices in the .dts file, the devices are there in the hardware. If you are sure the extension boards are safely hot pluggable, then all you need is some interface to enable and disable devices after booting. But that should be done in Linux generic way. So we should not export any omap_hwmod or omap_device things, and want to keep it __init only, and local to arch/arm/mach-omap2. I disagree. This is not something that is handled by just editing the dts. The way it is handled, is in the Linux generic way, we have a proper bus, and the drivers as compiled as standalone file. when you have an actual bus, that'd be correct. What do you think capebus is? It is an actual bus that allows you to do so. We're hitting a use case that wasn't there in omap until now. There a a whole bunch of conflicting capes. There's no way to instantiate them together. They must be instantiated only after their EEPROMs are read and they are matched to their corresponding cape drivers. why this requirement of instantiating them only after reading EEPROMs ? It's unnecessary to add that requirement, just do what Tony said (include my-awesome-cape.dtsi to bone.dts) and all i2c/spi devices should be created automatically. The thing is that there is no such thing as a cape-device. The cape is just a collection of I2C, 1-wire and SPI devices anyway. What we should instantiate is bmp085, tls2550, sht21, instead of instantiating beagle-bone-weather-cape. What's the problem in just instantiating all of those from bone.dts ? Expose the EEPROMs to userland so whatever SW you guys have running on the bone can figure out what features to expose to the SDK which the user sees, but the kernel doesn't need to know that there is a weather-cape attached to the bone. The I2C/SPI devices are not a problem at all. Let me try to explain what the problem is, and why it all this is needed. First of all, capes may be relatively simple boards, which may function as a generic device - like the generic capes. They might not necessarily be simple. Some capes, for example the geiger cape have a number of components that perform a specific task; in this instance the driving circuit of the geiger tube and the event detector input. Other capes that are being designed now are even more complex, i.e. there's a radar cape, an fpga cape and so on. So for these kind of boards you will need a specific driver. That driver will probably use some generic-cape bits (like gpios, pwms, keys what-ever). But it will put them to use in the custom in-kernel driver in it's own way. You can't put that task to user-space, if it's ever slightly complex. So for really simple capes, after considerable pain you might, just
Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
Hi,
On Thu, Nov 01, 2012 at 12:39:30PM +0200, Pantelis Antoniou wrote:
lcd@0 {
compatible = adafruit,tft-lcd-1.8-red,
sitronix,st7735;
spi-max-frequency = 800;
reg = 0;
spi-cpol;
spi-cpha;
pinctrl-names = default;
pinctrl-0 = lcd_pins;
st7735-rst = gpio4 19 0;
st7735-dc = gpio4 21 0;
};
};
};
I guess there is no easy solution for that, but it looks to me that
what you have to do is to make the DT creation dynamic in your case.
Assuming you do not want to do that in the bootloader, you must do
that pretty early during the boot process to end up with a full
description of your DT tree before creating the devices.
Do it pretty early in the boot processes ended up with the am335xevm board
file in the PSP tree.
The whole set of possible cape designs cannot be controlled, nor do we want
to.
We want to empower users to come up with their own designs without having to
do any kernel/boot loader
hacking.
that's impossible since you will have to provide the capebus driver
anyway.
Each cape will have their own DTS and based on some board id you
will fix the DT dynamically.
My point is that the issue you are facing is a real limitation of
DT, so you should fix the DT core and not workaround it by creating
artificial bindings / drivers.
You still haven't described any mechanism to deal with all the use
cases I described.
DT can't and will not deal with the complexity that we're facing right
now.
and DT-itself shouldn't. I agree with Benoit that this should be built
at bootloader level, perhaps. Whatever you're doing in capebus, you
could do at kernel space, build your DT bindings in runtime, and pass
that DT blob to kernel.
One question though, what do you mean by some capes are full blown
devices with their own drivers ? Do you mean you have capes running
some other (RT)OS and communicating with linux somehow ? How does it
communicate to the bone ?
cheers
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
Hi Panto, On 11/1/2012 11:39 AM, Pantelis Antoniou wrote: Hi Benoit, On Nov 1, 2012, at 12:23 PM, Cousson, Benoit wrote: On 11/1/2012 8:02 AM, Pantelis Antoniou wrote: Hi Felibe, On Nov 1, 2012, at 12:14 AM, Felipe Balbi wrote: Hi, On Wed, Oct 31, 2012 at 11:36:25PM +0200, Pantelis Antoniou wrote: * Pantelis Antoniou pa...@antoniou-consulting.com [121031 13:14]: On Oct 31, 2012, at 9:55 PM, Benoit Cousson wrote: Yeah, I do agree. I'm confused as well. Only OMAP IPs under PRCM control could have an hwmod and thus must be handled by an omap_device. Any devices that is created later cannot be omap_device. The DT core will create regular platform_device for them. Since cape is an external board, it should have nothing to do with omap_device. Looking at your patch: da8xx-dt: Create da8xx DT adapter device I understand why you do that, but in fact that patch does not make sense to me :-( Why do you have to create an omap_device from the driver probe? The problem is that capes are not external boards in the normal sense as a PCI board is. In the PCI case the hardware that implements the desired functionality is on the PCI board, while in the cape case the hardware module is in the SoC. The cape most of the times is quite simple and contains passive components, leds or some kind of I2C/SPI devices. Ah now I see, you're talking about the beaglebone extension boards :) The way to deal with those properly is to just edit the board .dts entry to include omap-beaglebone-cape-xyz.dtsi whatever. That is what is being done... This is the fallout. You can't instantiate the omap_device early in the boot process like it was done up to now in the board file. You can only do that later in the boot process (for built-in cape drivers), or even after user-space has booted and the matching cape driver module has been loaded. Yes you can, just edit the .dts file for the extension board you have connected. This stuff should be DT only for sure, let's not even start adding platform_data entries for that. The omap_device entries for the omap internal devices will be created automatically during startup based on the .dts. Note that you can set status = disabled for the omap internal devices in the .dts file, the devices are there in the hardware. If you are sure the extension boards are safely hot pluggable, then all you need is some interface to enable and disable devices after booting. But that should be done in Linux generic way. So we should not export any omap_hwmod or omap_device things, and want to keep it __init only, and local to arch/arm/mach-omap2. I disagree. This is not something that is handled by just editing the dts. The way it is handled, is in the Linux generic way, we have a proper bus, and the drivers as compiled as standalone file. when you have an actual bus, that'd be correct. What do you think capebus is? It is an actual bus that allows you to do so. We're hitting a use case that wasn't there in omap until now. There a a whole bunch of conflicting capes. There's no way to instantiate them together. They must be instantiated only after their EEPROMs are read and they are matched to their corresponding cape drivers. why this requirement of instantiating them only after reading EEPROMs ? It's unnecessary to add that requirement, just do what Tony said (include my-awesome-cape.dtsi to bone.dts) and all i2c/spi devices should be created automatically. The thing is that there is no such thing as a cape-device. The cape is just a collection of I2C, 1-wire and SPI devices anyway. What we should instantiate is bmp085, tls2550, sht21, instead of instantiating beagle-bone-weather-cape. What's the problem in just instantiating all of those from bone.dts ? Expose the EEPROMs to userland so whatever SW you guys have running on the bone can figure out what features to expose to the SDK which the user sees, but the kernel doesn't need to know that there is a weather-cape attached to the bone. The I2C/SPI devices are not a problem at all. Let me try to explain what the problem is, and why it all this is needed. First of all, capes may be relatively simple boards, which may function as a generic device - like the generic capes. They might not necessarily be simple. Some capes, for example the geiger cape have a number of components that perform a specific task; in this instance the driving circuit of the geiger tube and the event detector input. Other capes that are being designed now are even more complex, i.e. there's a radar cape, an fpga cape and so on. So for these kind of boards you will need a specific driver. That driver will probably use some generic-cape bits (like gpios, pwms, keys what-ever). But it will put them to use in the custom in-kernel driver in it's own way. You can't put that task to user-space, if it's ever slightly complex. So for really simple capes, after considerable pain you might, just might, dump the problem to user-space and try to make
Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
Hi
On Nov 1, 2012, at 1:04 PM, Felipe Balbi wrote:
Hi,
On Thu, Nov 01, 2012 at 12:39:30PM +0200, Pantelis Antoniou wrote:
lcd@0 {
compatible = adafruit,tft-lcd-1.8-red,
sitronix,st7735;
spi-max-frequency = 800;
reg = 0;
spi-cpol;
spi-cpha;
pinctrl-names = default;
pinctrl-0 = lcd_pins;
st7735-rst = gpio4 19 0;
st7735-dc = gpio4 21 0;
};
};
};
I guess there is no easy solution for that, but it looks to me that
what you have to do is to make the DT creation dynamic in your case.
Assuming you do not want to do that in the bootloader, you must do
that pretty early during the boot process to end up with a full
description of your DT tree before creating the devices.
Do it pretty early in the boot processes ended up with the am335xevm board
file in the PSP tree.
The whole set of possible cape designs cannot be controlled, nor do we want
to.
We want to empower users to come up with their own designs without having to
do any kernel/boot loader
hacking.
that's impossible since you will have to provide the capebus driver
anyway.
The generic cape bus driver can handle the easy stuff. More complex
stuff can be supported with per-cape drivers.
Each cape will have their own DTS and based on some board id you
will fix the DT dynamically.
My point is that the issue you are facing is a real limitation of
DT, so you should fix the DT core and not workaround it by creating
artificial bindings / drivers.
You still haven't described any mechanism to deal with all the use
cases I described.
DT can't and will not deal with the complexity that we're facing right
now.
and DT-itself shouldn't. I agree with Benoit that this should be built
at bootloader level, perhaps. Whatever you're doing in capebus, you
could do at kernel space, build your DT bindings in runtime, and pass
that DT blob to kernel.
We're just passing the buck someplace else. We're not fixing the problem.
What makes you think that dealing with this in the bootloader is going
to be simpler?
One question though, what do you mean by some capes are full blown
devices with their own drivers ? Do you mean you have capes running
some other (RT)OS and communicating with linux somehow ? How does it
communicate to the bone ?
Some have FPGAs.
https://specialcomp.com/beaglebone/BeagleBone_FPGA.html
Some capes have their own MCUs.
A recent one has an 6502 communicating with uio_pruss.
https://github.com/ohporter/b6502
What I'm saying is that there are simple capes, that are just DT devices
which can be handled via cape-generic. The complex ones need their own
drivers which need a place to live.
Capebus handles both.
cheers
--
balbi
Regards
-- Pantelis
--
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] ARM: OMAP4: ID: Improve features detection and check
On Thursday 01 November 2012 03:53 PM, Ivan Khoronzhuk wrote:
Replaces several flags bearing the same meaning. There is no need
to set flags due to different omap types here, it can be checked
in appropriate places as well.
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
arch/arm/mach-omap2/id.c | 25 +++--
arch/arm/mach-omap2/soc.h |8 ++--
2 files changed, 9 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index cf2362c..3c47a19 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -28,6 +28,9 @@
#include soc.h
#include control.h
+#define OMAP4_SILICON_TYPE_STANDARD0x01
+#define OMAP4_SILICON_TYPE_PERFORMANCE 0x02
+
static unsigned int omap_revision;
static const char *cpu_rev;
u32 omap_features;
@@ -273,25 +276,11 @@ void __init omap4xxx_check_features(void)
{
u32 si_type;
- if (cpu_is_omap443x())
- omap_features |= OMAP4_HAS_MPU_1GHZ;
-
+ si_type =
+ (read_tap_reg(OMAP4_CTRL_MODULE_CORE_STD_FUSE_PROD_ID_1) 16) 0x03;
- if (cpu_is_omap446x()) {
- si_type =
- read_tap_reg(OMAP4_CTRL_MODULE_CORE_STD_FUSE_PROD_ID_1);
- switch ((si_type (3 16)) 16) {
- case 2:
- /* High performance device */
- omap_features |= OMAP4_HAS_MPU_1_5GHZ;
- break;
- case 1:
- default:
- /* Standard device */
- omap_features |= OMAP4_HAS_MPU_1_2GHZ;
- break;
- }
- }
+ if (si_type == OMAP4_SILICON_TYPE_PERFORMANCE)
+ omap_features = OMAP4_HAS_PERF_SILICON;
Well the detection isn't for performance/standard but there are some
features depend on it. For example 1 GHz doesn't DPLL DCC enable feature
where as 1.2 GHz, 1.5 GHz doesn't need. This is the main reason this
information is also effused. Have you considered this aspect while
creating this patch ?
Regards
Santosh
--
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
Hi Benoit, On Nov 1, 2012, at 1:26 PM, Cousson, Benoit wrote: Hi Panto, On 11/1/2012 11:39 AM, Pantelis Antoniou wrote: Hi Benoit, On Nov 1, 2012, at 12:23 PM, Cousson, Benoit wrote: On 11/1/2012 8:02 AM, Pantelis Antoniou wrote: Hi Felibe, On Nov 1, 2012, at 12:14 AM, Felipe Balbi wrote: Hi, On Wed, Oct 31, 2012 at 11:36:25PM +0200, Pantelis Antoniou wrote: * Pantelis Antoniou pa...@antoniou-consulting.com [121031 13:14]: On Oct 31, 2012, at 9:55 PM, Benoit Cousson wrote: Yeah, I do agree. I'm confused as well. Only OMAP IPs under PRCM control could have an hwmod and thus must be handled by an omap_device. Any devices that is created later cannot be omap_device. The DT core will create regular platform_device for them. Since cape is an external board, it should have nothing to do with omap_device. Looking at your patch: da8xx-dt: Create da8xx DT adapter device I understand why you do that, but in fact that patch does not make sense to me :-( Why do you have to create an omap_device from the driver probe? The problem is that capes are not external boards in the normal sense as a PCI board is. In the PCI case the hardware that implements the desired functionality is on the PCI board, while in the cape case the hardware module is in the SoC. The cape most of the times is quite simple and contains passive components, leds or some kind of I2C/SPI devices. Ah now I see, you're talking about the beaglebone extension boards :) The way to deal with those properly is to just edit the board .dts entry to include omap-beaglebone-cape-xyz.dtsi whatever. That is what is being done... This is the fallout. You can't instantiate the omap_device early in the boot process like it was done up to now in the board file. You can only do that later in the boot process (for built-in cape drivers), or even after user-space has booted and the matching cape driver module has been loaded. Yes you can, just edit the .dts file for the extension board you have connected. This stuff should be DT only for sure, let's not even start adding platform_data entries for that. The omap_device entries for the omap internal devices will be created automatically during startup based on the .dts. Note that you can set status = disabled for the omap internal devices in the .dts file, the devices are there in the hardware. If you are sure the extension boards are safely hot pluggable, then all you need is some interface to enable and disable devices after booting. But that should be done in Linux generic way. So we should not export any omap_hwmod or omap_device things, and want to keep it __init only, and local to arch/arm/mach-omap2. I disagree. This is not something that is handled by just editing the dts. The way it is handled, is in the Linux generic way, we have a proper bus, and the drivers as compiled as standalone file. when you have an actual bus, that'd be correct. What do you think capebus is? It is an actual bus that allows you to do so. We're hitting a use case that wasn't there in omap until now. There a a whole bunch of conflicting capes. There's no way to instantiate them together. They must be instantiated only after their EEPROMs are read and they are matched to their corresponding cape drivers. why this requirement of instantiating them only after reading EEPROMs ? It's unnecessary to add that requirement, just do what Tony said (include my-awesome-cape.dtsi to bone.dts) and all i2c/spi devices should be created automatically. The thing is that there is no such thing as a cape-device. The cape is just a collection of I2C, 1-wire and SPI devices anyway. What we should instantiate is bmp085, tls2550, sht21, instead of instantiating beagle-bone-weather-cape. What's the problem in just instantiating all of those from bone.dts ? Expose the EEPROMs to userland so whatever SW you guys have running on the bone can figure out what features to expose to the SDK which the user sees, but the kernel doesn't need to know that there is a weather-cape attached to the bone. The I2C/SPI devices are not a problem at all. Let me try to explain what the problem is, and why it all this is needed. First of all, capes may be relatively simple boards, which may function as a generic device - like the generic capes. They might not necessarily be simple. Some capes, for example the geiger cape have a number of components that perform a specific task; in this instance the driving circuit of the geiger tube and the event detector input. Other capes that are being designed now are even more complex, i.e. there's a radar cape, an fpga cape and so on. So for these kind of boards you will need a specific driver. That driver will probably use some generic-cape bits (like gpios, pwms, keys what-ever). But it will put them to use in the custom in-kernel driver in it's own way. You can't
Re: Fwd: [PATCHv2] Input: omap4-keypad: Add pinctrl support
Linus Walleij linus.wall...@linaro.org writes: On Wed, Oct 31, 2012 at 9:10 PM, Kevin Hilman khil...@deeprootsystems.com wrote: Linus Walleij linus.wall...@linaro.org writes: piece of hardware, this would be the right thing to do, and I think the in-kernel examples are all simple, e.g. arch/arm/mach-omap2/powerdomain* is all about power domains and nothing else, FYI... that code isn't the same as PM domain. This sort of points to a core problem here. Our terminologies are ambiguous that we cannot understand each others code. As long as linux/pm_domain.h begins: /* * pm_domain.h - Definitions and headers related to device power domains. * But arguably that should just be patched (I think there are a few remnants in the code still implying that these things are only about power). Agreed. The terminology is confusing, and any situations like this in the code/comments/docs should be patched. When PM domains were introduced, I was the first to complain that we shouldn't use the term power domain so as not to be confused with HW concepts, so we settled on the term 'PM domain.' Ultimately, it's just a configurable grouping of devices whose callbacks happen during PM transitions. That code is for the *hardware* powerdomains, not the software concept of PM domain. In OMAP, PM domain is implmented at the omap_device level. And omap_device is the abstraction of an IP block that knows about all the PM related register settings, clocks, HW powerdomain, voltage domain, PM related pin-muxing etc. etc.All of these things are abstracted in an omap_device, so that the PM domain implementation for OMAP looks rather simple (c.f. omap_device_pm_domain in arch/arm/plat-omap/omap_device.c.) OK following now... I think the lesser of two evils is the distributed approach, The pinctrl examples I've seen mentioned so far are all PM related (sleep, idle, wakeup, etc.) so to me I think they still belong in PM domains (and that's how we handle the PM related pins in OMAP.) Well, the pinctrl grabbers in these drivers are using these states also for platforms that do not even select CONFIG_PM. For example mach-nomadik is quite happy that the PL011 driver is thusly muxing in its pins. And would require refactoring to use PM domains. If CONFIG_PM is disabled, then is it safe to assume that the pins in question are probably only done once at init time. I assume during -probe(). ? So basically this requirement comes down to: - When dealing with a SoC IP block driver - That need to multiplex pins - Then your SoC must select CONFIG_PM and CONFIG_PM_RUNTIME andb CONFIG_PM_GENERIC_DOMAINS and implement proper domain handling hooks. Is this correct? I would say yes. Currently, PM domains are the way to hook SoC-specific integration details into PM transitions. However, if what we want/need are only ways to introduce SoC-specific integration details into non-PM transitions (e.g. probe/remove), maybe bus notifiers would suffice here. e.g. you'd get a bus notifier when the device is added/attached and any init-time pinctrl setup could be done then. This still keeps drivers clean of SoC-specific integration data/code, and also allows that to happen whether or not PM features are enabled. Kevin -- 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 05/13] ARM: OMAP2+: PRCM: create SoC-specific chip restart functions
Here's an update of this one.
- Paul
From: Paul Walmsley p...@pwsan.com
Date: Mon, 29 Oct 2012 20:56:07 -0600
Subject: [PATCH] ARM: OMAP2+: PRCM: create SoC-specific chip restart
functions
Split omap_prcm_restart() from mach-omap2/prcm.c into SoC-specific
variants. These functions need to be able to save the reboot reason
into the scratchpad RAM. This implies a dependency on both the PRM
and SCM IP blocks, so they've been moved into their own file. This
will eventually call functions in the PRM and SCM drivers, once those
are created.
Vaibhav Hiremath hvaib...@ti.com identified an unused prototype in
the first version of this patch - now removed.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Vaibhav Hiremath hvaib...@ti.com
Tested-by: Vaibhav Hiremath hvaib...@ti.com
---
arch/arm/mach-omap2/Makefile|5 +++
arch/arm/mach-omap2/common.h| 24 +
arch/arm/mach-omap2/omap2-restart.c | 65 +++
arch/arm/mach-omap2/omap3-restart.c | 36 +++
arch/arm/mach-omap2/omap4-common.c | 16 +
5 files changed, 146 insertions(+)
create mode 100644 arch/arm/mach-omap2/omap2-restart.c
create mode 100644 arch/arm/mach-omap2/omap3-restart.c
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index ae87a3e..1988810 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -50,6 +50,11 @@ AFLAGS_sram242x.o:=-Wa,-march=armv6
AFLAGS_sram243x.o :=-Wa,-march=armv6
AFLAGS_sram34xx.o :=-Wa,-march=armv7-a
+# Restart code (OMAP4/5 currently in omap4-common.c)
+obj-$(CONFIG_SOC_OMAP2420) += omap2-restart.o
+obj-$(CONFIG_SOC_OMAP2430) += omap2-restart.o
+obj-$(CONFIG_ARCH_OMAP3) += omap3-restart.o
+
# Pin multiplexing
obj-$(CONFIG_SOC_OMAP2420) += mux2420.o
obj-$(CONFIG_SOC_OMAP2430) += mux2430.o
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index b8f7710..3f5aa9d 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -121,6 +121,30 @@ void omap4430_init_late(void);
int omap2_common_pm_late_init(void);
void omap_prcm_restart(char, const char *);
+#if defined(CONFIG_SOC_OMAP2420) || defined(CONFIG_SOC_OMAP2430)
+void omap2xxx_restart(char mode, const char *cmd);
+#else
+static inline void omap2xxx_restart(char mode, const char *cmd)
+{
+}
+#endif
+
+#ifdef CONFIG_ARCH_OMAP3
+void omap3xxx_restart(char mode, const char *cmd);
+#else
+static inline void omap3xxx_restart(char mode, const char *cmd)
+{
+}
+#endif
+
+#if defined(CONFIG_ARCH_OMAP4) || defined(CONFIG_SOC_OMAP5)
+void omap44xx_restart(char mode, const char *cmd);
+#else
+static inline void omap44xx_restart(char mode, const char *cmd)
+{
+}
+#endif
+
/* This gets called from mach-omap2/io.c, do not call this */
void __init omap2_set_globals_tap(u32 class, void __iomem *tap);
diff --git a/arch/arm/mach-omap2/omap2-restart.c
b/arch/arm/mach-omap2/omap2-restart.c
new file mode 100644
index 000..be6bc89
--- /dev/null
+++ b/arch/arm/mach-omap2/omap2-restart.c
@@ -0,0 +1,65 @@
+/*
+ * omap2-restart.c - code common to all OMAP2xxx machines.
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Paul Walmsley
+ *
+ * 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.
+ */
+#include linux/kernel.h
+#include linux/init.h
+#include linux/clk.h
+#include linux/io.h
+
+#include common.h
+#include prm2xxx.h
+
+/*
+ * reset_virt_prcm_set_ck, reset_sys_ck: pointers to the virt_prcm_set
+ * clock and the sys_ck. Used during the reset process
+ */
+static struct clk *reset_virt_prcm_set_ck, *reset_sys_ck;
+
+/* Reboot handling */
+
+/**
+ * omap2xxx_restart - Set DPLL to bypass mode for reboot to work
+ *
+ * Set the DPLL to bypass so that reboot completes successfully. No
+ * return value.
+ */
+void omap2xxx_restart(char mode, const char *cmd)
+{
+ u32 rate;
+
+ rate = clk_get_rate(reset_sys_ck);
+ clk_set_rate(reset_virt_prcm_set_ck, rate);
+
+ /* XXX Should save the cmd argument for use after the reboot */
+
+ omap2xxx_prm_dpll_reset(); /* never returns */
+ while (1);
+}
+
+/**
+ * omap2xxx_common_look_up_clks_for_reset - look up clocks needed for restart
+ *
+ * Some clocks need to be looked up in advance for the SoC restart
+ * operation to work - see omap2xxx_restart(). Returns -EINVAL upon
+ * error or 0 upon success.
+ */
+static int __init omap2xxx_common_look_up_clks_for_reset(void)
+{
+ reset_virt_prcm_set_ck = clk_get(NULL, virt_prcm_set);
+ if (IS_ERR(reset_virt_prcm_set_ck))
+ return -EINVAL;
+
+ reset_sys_ck = clk_get(NULL, sys_ck);
+ if (IS_ERR(reset_sys_ck))
+ return -EINVAL;
+
+ return 0;
+}
Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
tl;dr: please suggest an actual solution that allows plugplay when plugging in multiple capes and applying power after that. Preferably one that doesn't pass the buck to u-boot. Op 1 nov. 2012, om 12:26 heeft Cousson, Benoit b-cous...@ti.com het volgende geschreven: Hi Panto, On 11/1/2012 11:39 AM, Pantelis Antoniou wrote: Hi Benoit, On Nov 1, 2012, at 12:23 PM, Cousson, Benoit wrote: On 11/1/2012 8:02 AM, Pantelis Antoniou wrote: Hi Felibe, On Nov 1, 2012, at 12:14 AM, Felipe Balbi wrote: Hi, On Wed, Oct 31, 2012 at 11:36:25PM +0200, Pantelis Antoniou wrote: * Pantelis Antoniou pa...@antoniou-consulting.com [121031 13:14]: On Oct 31, 2012, at 9:55 PM, Benoit Cousson wrote: Yeah, I do agree. I'm confused as well. Only OMAP IPs under PRCM control could have an hwmod and thus must be handled by an omap_device. Any devices that is created later cannot be omap_device. The DT core will create regular platform_device for them. Since cape is an external board, it should have nothing to do with omap_device. Looking at your patch: da8xx-dt: Create da8xx DT adapter device I understand why you do that, but in fact that patch does not make sense to me :-( Why do you have to create an omap_device from the driver probe? The problem is that capes are not external boards in the normal sense as a PCI board is. In the PCI case the hardware that implements the desired functionality is on the PCI board, while in the cape case the hardware module is in the SoC. The cape most of the times is quite simple and contains passive components, leds or some kind of I2C/SPI devices. Ah now I see, you're talking about the beaglebone extension boards :) The way to deal with those properly is to just edit the board .dts entry to include omap-beaglebone-cape-xyz.dtsi whatever. That is what is being done... This is the fallout. You can't instantiate the omap_device early in the boot process like it was done up to now in the board file. You can only do that later in the boot process (for built-in cape drivers), or even after user-space has booted and the matching cape driver module has been loaded. Yes you can, just edit the .dts file for the extension board you have connected. This stuff should be DT only for sure, let's not even start adding platform_data entries for that. The omap_device entries for the omap internal devices will be created automatically during startup based on the .dts. Note that you can set status = disabled for the omap internal devices in the .dts file, the devices are there in the hardware. If you are sure the extension boards are safely hot pluggable, then all you need is some interface to enable and disable devices after booting. But that should be done in Linux generic way. So we should not export any omap_hwmod or omap_device things, and want to keep it __init only, and local to arch/arm/mach-omap2. I disagree. This is not something that is handled by just editing the dts. The way it is handled, is in the Linux generic way, we have a proper bus, and the drivers as compiled as standalone file. when you have an actual bus, that'd be correct. What do you think capebus is? It is an actual bus that allows you to do so. We're hitting a use case that wasn't there in omap until now. There a a whole bunch of conflicting capes. There's no way to instantiate them together. They must be instantiated only after their EEPROMs are read and they are matched to their corresponding cape drivers. why this requirement of instantiating them only after reading EEPROMs ? It's unnecessary to add that requirement, just do what Tony said (include my-awesome-cape.dtsi to bone.dts) and all i2c/spi devices should be created automatically. The thing is that there is no such thing as a cape-device. The cape is just a collection of I2C, 1-wire and SPI devices anyway. What we should instantiate is bmp085, tls2550, sht21, instead of instantiating beagle-bone-weather-cape. What's the problem in just instantiating all of those from bone.dts ? Expose the EEPROMs to userland so whatever SW you guys have running on the bone can figure out what features to expose to the SDK which the user sees, but the kernel doesn't need to know that there is a weather-cape attached to the bone. The I2C/SPI devices are not a problem at all. Let me try to explain what the problem is, and why it all this is needed. First of all, capes may be relatively simple boards, which may function as a generic device - like the generic capes. They might not necessarily be simple. Some capes, for example the geiger cape have a number of components that perform a specific task; in this instance the driving circuit of the geiger tube and the event detector input. Other capes that are being designed now are even more complex, i.e. there's a radar cape, an fpga cape and so on. So for these kind of boards
Re: [PATCHv2] Input: omap4-keypad: Add pinctrl support
On Thu, Nov 01, 2012 at 09:54:00AM +0100, Linus Walleij wrote: Well, the pinctrl grabbers in these drivers are using these states also for platforms that do not even select CONFIG_PM. For example mach-nomadik is quite happy that the PL011 driver is thusly muxing in its pins. And would require refactoring to use PM domains. So basically this requirement comes down to: - When dealing with a SoC IP block driver - That need to multiplex pins - Then your SoC must select CONFIG_PM and CONFIG_PM_RUNTIME and CONFIG_PM_GENERIC_DOMAINS and implement proper domain handling hooks. Is this correct? And for Mark, Dmitry, does this correspond to your view? For the pin hogging I'd actually been thinking separately that we should just have the device core do a devm_pinctrl_get_set_default() prior to probing the device and store the result in the struct device. That would immediately remove almost all of the current pinctrl users, users that do need to do things with the data or check the result can then pick up the pinctrl pointer from the device struct. It's actually something that needs to be acknowledged by the ARM SoC maintainers, because they will be the ones telling all subarch maintainers to go implement full PM handling with these three frameworks whenever an SoC driver want to handle pins. Well, they're going to have to implement it somewhere anyway - either in the drivers or in the SoC stuff. And IIUC not only pins but also silicon block clocks? I can surely fix these for my systems, but it really needs to be enforced widely or it will be a mess. We definitely need to decide if it's something that should be open coded everywhere. signature.asc Description: Digital signature
[GIT PULL] ARM: OMAP: second set of PRCM cleanups for 3.8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tony The following changes since commit 7fc54fd3084457c7f11b9e2e1e3fcd19a3badc33: Merge branch 'omap-for-v3.8/cleanup-headers' into omap-for-v3.8/cleanup-prcm (2012-10-26 13:32:22 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/omap-cleanup-b-for-3.8 for you to fetch changes up to f17d60d20eb8e679cdd1e9d507394237e58ce0d8: ARM: OMAP2+: PRCM: remove obsolete prcm.[ch] (2012-11-01 04:48:18 -0600) - Second set of OMAP PRCM cleanups for 3.8. These patches remove the use of omap_prcm_get_reset_sources() from the OMAP watchdog driver, and remove mach-omap2/prcm.c and plat-omap/include/plat/prcm.h. Basic test logs for this branch on top of Tony's cleanup-prcm branch at commit 7fc54fd3084457c7f11b9e2e1e3fcd19a3badc33 are here: http://www.pwsan.com/omap/testlogs/prcm_cleanup_b_3.8/20121101044824/ However, cleanup-prcm at 7fc54fd3 does not build for several Kconfigs here and doesn't include some fixes that are needed for a successful test. With several reverts, fixes, and workarounds applied, the following test logs were obtained: http://www.pwsan.com/omap/testlogs/TEST_prcm_cleanup_b_3.8/20121101045401/ which indicate that the series tests cleanly. - vmlinux object size (delta in bytes from test_cleanup-prcm_7fc54fd_v3.7-rc (7fc54fd3084457c7f11b9e2e1e3fcd19a3badc33)): text data bsstotal kernel -252 -560 -308 am33xx_only +16 -560 -40 n800_multi_omap2xxx +232 -240 +208 n800_only_a +88 -240 +64 omap1_defconfig 0000 omap1_defconfig_1510innovator_only +132 -80 +124 omap1_defconfig_5912osk_only +652 -2240 +428 omap2plus_defconfig +200 -240 +176 omap2plus_defconfig_2430sdp_only +652 -2320 +420 omap2plus_defconfig_cpupm +708 -2480 +460 omap2plus_defconfig_no_pm +200 -1360 +64 omap2plus_defconfig_omap2_4_only +4316 -1280+4188 omap2plus_defconfig_omap3_4_only +196 -560 +140 rmk_omap3430_ldp_oldconfig +60 -560 +4 rmk_omap4430_sdp_oldconfig Paul Walmsley (17): ARM: OMAP1: CGRM: fix omap1_get_reset_sources() return type ARM: OMAP2+: WDT: move init; add read_reset_sources pdata function pointer watchdog: OMAP: use standard GETBOOTSTATUS interface; use platform_data fn ptr ARM: OMAP2+: PRCM: remove omap_prcm_get_reset_sources() ARM: OMAP2+: common: remove mach-omap2/common.c globals and map_common_io code ARM: OMAP2/3: PRM: add SoC reset functions (using the CORE DPLL method) ARM: OMAP2xxx: clock: remove global 'dclk' variable ARM: OMAP2xxx: clock: move virt_prcm_set code into clkt2xxx_virt_prcm_set.c ARM: OMAP2+: PRCM: create SoC-specific chip restart functions ARM: OMAP2+: board files: use SoC-specific system restart functions ARM: OMAP2xxx: APLL/CM: convert to use omap2_cm_wait_module_ready() ARM: OMAP2+: CM/clock: convert _omap2_module_wait_ready() to use SoC-independent CM functions ARM: OMAP2+: PRCM: remove omap2_cm_wait_idlest() ARM: OMAP2+: PRCM: split and relocate the PRM/CM globals setup ARM: OMAP2+: PRCM: consolidate PRCM-related timeout macros ARM: OMAP2+: hwmod: call to _omap4_disable_module() should use the SoC-specific call ARM: OMAP2+: PRCM: remove obsolete prcm.[ch] arch/arm/mach-omap1/common.h |2 +- arch/arm/mach-omap1/devices.c| 21 ++- arch/arm/mach-omap1/reset.c |9 +- arch/arm/mach-omap2/Makefile |7 +- arch/arm/mach-omap2/am33xx.h |1 + arch/arm/mach-omap2/board-2430sdp.c |2 +- arch/arm/mach-omap2/board-3430sdp.c |2 +- arch/arm/mach-omap2/board-3630sdp.c |2 +- arch/arm/mach-omap2/board-4430sdp.c |2 +- arch/arm/mach-omap2/board-am3517crane.c |2 +- arch/arm/mach-omap2/board-am3517evm.c|2 +- arch/arm/mach-omap2/board-apollon.c |2 +- arch/arm/mach-omap2/board-cm-t35.c | 18 +-- arch/arm/mach-omap2/board-cm-t3517.c |2 +- arch/arm/mach-omap2/board-devkit8000.c |2 +- arch/arm/mach-omap2/board-generic.c | 10 +- arch/arm/mach-omap2/board-h4.c |2 +- arch/arm/mach-omap2/board-igep0020.c |4 +- arch/arm/mach-omap2/board-ldp.c |2 +- arch/arm/mach-omap2/board-n8x0.c |6 +- arch/arm/mach-omap2/board-omap3beagle.c |2 +- arch/arm/mach-omap2/board-omap3evm.c |2 +-
Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
Hi,
On Thu, Nov 01, 2012 at 01:26:10PM +0200, Pantelis Antoniou wrote:
Hi
On Nov 1, 2012, at 1:04 PM, Felipe Balbi wrote:
Hi,
On Thu, Nov 01, 2012 at 12:39:30PM +0200, Pantelis Antoniou wrote:
lcd@0 {
compatible = adafruit,tft-lcd-1.8-red,
sitronix,st7735;
spi-max-frequency = 800;
reg = 0;
spi-cpol;
spi-cpha;
pinctrl-names = default;
pinctrl-0 = lcd_pins;
st7735-rst = gpio4 19 0;
st7735-dc = gpio4 21 0;
};
};
};
I guess there is no easy solution for that, but it looks to me that
what you have to do is to make the DT creation dynamic in your case.
Assuming you do not want to do that in the bootloader, you must do
that pretty early during the boot process to end up with a full
description of your DT tree before creating the devices.
Do it pretty early in the boot processes ended up with the am335xevm board
file in the PSP tree.
The whole set of possible cape designs cannot be controlled, nor do we
want to.
We want to empower users to come up with their own designs without having
to do any kernel/boot loader
hacking.
that's impossible since you will have to provide the capebus driver
anyway.
The generic cape bus driver can handle the easy stuff. More complex
stuff can be supported with per-cape drivers.
likewise:
the generic stuff can be handled by FDT easily, the more complex stuff
can be supported by dynamically changing FDT blob, no ?
Each cape will have their own DTS and based on some board id you
will fix the DT dynamically.
My point is that the issue you are facing is a real limitation of
DT, so you should fix the DT core and not workaround it by creating
artificial bindings / drivers.
You still haven't described any mechanism to deal with all the use
cases I described.
DT can't and will not deal with the complexity that we're facing right
now.
and DT-itself shouldn't. I agree with Benoit that this should be built
at bootloader level, perhaps. Whatever you're doing in capebus, you
could do at kernel space, build your DT bindings in runtime, and pass
that DT blob to kernel.
We're just passing the buck someplace else. We're not fixing the problem.
What makes you think that dealing with this in the bootloader is going
to be simpler?
I never said it was supposed to be simpler, it just doesn't sound like
something the kernel should care about. Kernel cares about the
One question though, what do you mean by some capes are full blown
devices with their own drivers ? Do you mean you have capes running
some other (RT)OS and communicating with linux somehow ? How does it
communicate to the bone ?
Some have FPGAs.
https://specialcomp.com/beaglebone/BeagleBone_FPGA.html
how does linux communicate with those ? What they are matters very
little ;-) All we need is an interface to load binaries to the FPGA.
Some capes have their own MCUs.
A recent one has an 6502 communicating with uio_pruss.
https://github.com/ohporter/b6502
that uses remoteproc, so I assume it's using OMAP's mailbox ?
Again I say that this is not a 'capebus', it's just another device
which we use another interface to talk to.
i2c devices will be children of the omap i2c controller, spi devices
will be children of the omap mcspi, GPMC devices will need the GPMC
controller and so on, but none of this looks like argument to introduce
a fake bus into the kernel.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
Hi,
On Nov 1, 2012, at 2:40 PM, Felipe Balbi wrote:
Hi,
On Thu, Nov 01, 2012 at 01:26:10PM +0200, Pantelis Antoniou wrote:
Hi
On Nov 1, 2012, at 1:04 PM, Felipe Balbi wrote:
Hi,
On Thu, Nov 01, 2012 at 12:39:30PM +0200, Pantelis Antoniou wrote:
lcd@0 {
compatible = adafruit,tft-lcd-1.8-red,
sitronix,st7735;
spi-max-frequency = 800;
reg = 0;
spi-cpol;
spi-cpha;
pinctrl-names = default;
pinctrl-0 = lcd_pins;
st7735-rst = gpio4 19 0;
st7735-dc = gpio4 21 0;
};
};
};
I guess there is no easy solution for that, but it looks to me that
what you have to do is to make the DT creation dynamic in your case.
Assuming you do not want to do that in the bootloader, you must do
that pretty early during the boot process to end up with a full
description of your DT tree before creating the devices.
Do it pretty early in the boot processes ended up with the am335xevm board
file in the PSP tree.
The whole set of possible cape designs cannot be controlled, nor do we
want to.
We want to empower users to come up with their own designs without having
to do any kernel/boot loader
hacking.
that's impossible since you will have to provide the capebus driver
anyway.
The generic cape bus driver can handle the easy stuff. More complex
stuff can be supported with per-cape drivers.
likewise:
the generic stuff can be handled by FDT easily, the more complex stuff
can be supported by dynamically changing FDT blob, no ?
No. You're missing the point. Up until we read the EEPROM we don't know
what to dynamically change in the device tree (not the blob). What you
will end up is something like capebus again. Only you're going to reinvent it
with a different name.
Each cape will have their own DTS and based on some board id you
will fix the DT dynamically.
My point is that the issue you are facing is a real limitation of
DT, so you should fix the DT core and not workaround it by creating
artificial bindings / drivers.
You still haven't described any mechanism to deal with all the use
cases I described.
DT can't and will not deal with the complexity that we're facing right
now.
and DT-itself shouldn't. I agree with Benoit that this should be built
at bootloader level, perhaps. Whatever you're doing in capebus, you
could do at kernel space, build your DT bindings in runtime, and pass
that DT blob to kernel.
We're just passing the buck someplace else. We're not fixing the problem.
What makes you think that dealing with this in the bootloader is going
to be simpler?
I never said it was supposed to be simpler, it just doesn't sound like
something the kernel should care about. Kernel cares about the
I just disagree here. The kernel should provide services that make the life
of users easier, not the lives of the kernel developers easier.
One question though, what do you mean by some capes are full blown
devices with their own drivers ? Do you mean you have capes running
some other (RT)OS and communicating with linux somehow ? How does it
communicate to the bone ?
Some have FPGAs.
https://specialcomp.com/beaglebone/BeagleBone_FPGA.html
how does linux communicate with those ? What they are matters very
little ;-) All we need is an interface to load binaries to the FPGA.
We can not know what people will come up with. It might have a few GPIOs
to load the bitfile to the FPGA, but after that, no-one can tell.
I might not interface to Linux at all; it might interface via I2C, or RS232.
Chances are, it won't fit in any kind of known drivers of linux.
Some guy is using an FPGA for SDR, another is making a radar cape.
These guys don't give a damn frankly about Linux. What they do care about
is having a cheap/easy to develop platform for their own little widget.
If you are going to ask from the to hunt down their own dts and assemble
from various dtsi's they'll just move to something else.
Which is a shame, cause we do have a nice platform here.
Some capes have their own MCUs.
A recent one has an 6502 communicating with uio_pruss.
https://github.com/ohporter/b6502
that uses remoteproc, so I assume it's using OMAP's mailbox ?
Again I say that this is not a 'capebus', it's just another device
which we use another interface to talk to.
i2c devices will be children of the omap i2c controller, spi devices
will be children of the omap mcspi, GPMC devices will need the GPMC
controller and so on, but none of this looks like argument to introduce
a fake bus into the kernel.
I'll let the users of said bus to do the talking. You're just flat out
wrong IMO.
--
balbi
Regards
-- Pantelis
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a
Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
Hi, On Thu, Nov 01, 2012 at 01:00:21PM +0100, Koen Kooi wrote: tl;dr: please suggest an actual solution that allows plugplay when plugging in multiple capes and applying power after that. Preferably one that doesn't pass the buck to u-boot. I can think of a few ways: 1) ship your distribution with all necessary drivers and let udev handle driver probing. clearly this will require constant updates for the distribution as new capes are developed. But IIUC, that's the same with Arduino where new libraries are added to the Arduino OS. 2) ship with drivers for EEPROMs only and setup a repository of drivers this would require every driver to be packaged separately, then you create a setup where bone's userland will use EEPROMs data to figure out which drivers it needs, pass that information to SDK via USB, then SDK downloads all necessary/missing packages, sends them to bone via USB and all packages are installed on the bone. Note that since packages would be 'installed', this would be a one-time-only thing. 3) realize that if your user can build an FPGA cape, s/he can most likely write code and adding/recompiling kernel shouldn't be the biggest of his/her worries (no comments to this one, I understand it's not feasible) in any case, capebus sounds like something which is hugely unnecessary. ps: at least for the I2C subsystem, i2c-core can detect for you if your driver provides -detect() method. Op 1 nov. 2012, om 12:26 heeft Cousson, Benoit b-cous...@ti.com het volgende geschreven: FWIW, we do have a similar, but simpler, problem with the beagle / beagle-xm and panda / panda-es. But for the moment we are just using a different DTS for each board. A different DTS for each board combination... There alot more capes for the bone that they are for the beagle the panda. And more are going to come, but not necessarily from people that have any connection to TI or CCO. Sure, but my point is that your solution will not solve our problem :-) This is a generic problem that you address with a very custom / specific approach. You still haven't described how I could solve the issue of conflicting capes using a single DTS. Well I don't have the solution otherwise I will have done it already :-) My point is that the solution has to be in the DT core if not in the bootloader. snarky commentSo when we at beagleboard.org handled the beagleboard and beagleboard xM expansionboards in the bootloader (detection, muxing, etc) we were told it was wrong and we should handle it in the kernel and if we waited a bit, DT would solve everything. And now that we actually handle it in the kernel you are saying that it is wrong and we should handle it in the bootloader and that DT won't solve everything. I guess someone will now tell us that uEFI will fix everything./snarky comment Apart from that, you and others still fail to tell us how you want to handle a user (or customer) that buys a beaglebone, an LCD cape, a weatherstation cape and a geiger counter cape and plugs those together and powers them on. With the evil TI vendor tree and extra patches the boardfile reads the eeproms and tries its best to instantiate all the platform data. One of the capes won't have working LEDs since appending to the leds-gpio struct is pretty much impossible in this couldn't you just instantiate multiple leds-gpio device ? situation. But it gets a picture on the screen, blinks LEDs and does largely what the user expects. With capebus we get: 1) da8xx-fb which lacks DT bindingsp[1] receives plaftorm data to match the LCD this is something which could be fixed at the driver level, right ? :-) 2) the i2c sensors on the weathercape are registered that will work with or without capebus. 3) the one-wire bus on the weathercape gets registered also should work with or without capebus. 4) the LEDs on the lcd cape get registered5 also works with or without capebus. 5) the LED on the geigercape gets registered and adds a custom trigger also works with or without capebus. 6) the ADC, which again, lacks DT bindings[2], receives plaftorm data and a custom IIO binding driver problem. 7) pinctrl sets the pinmuxes for the above also works with or without capebus. In other words: plug play, even for devices with drivers that are still lacking DT support. I _do_ agree with you that we could have a grace period where DT and non-DT would boot together, but apparently that's not something which isn't trivial to do. I guess Benoit might also be concerned that if we add such an infrastructure than conversion to DT will never finish heh. Now please explain to me why you think it's such an awesome idea that the users will need to find the right dtsi files (multiple revisions of the lcd cape exist), include them in the dts, run dtc, add a
Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
Hi, On Thu, Nov 01, 2012 at 02:57:26PM +0200, Pantelis Antoniou wrote: Each cape will have their own DTS and based on some board id you will fix the DT dynamically. My point is that the issue you are facing is a real limitation of DT, so you should fix the DT core and not workaround it by creating artificial bindings / drivers. You still haven't described any mechanism to deal with all the use cases I described. DT can't and will not deal with the complexity that we're facing right now. and DT-itself shouldn't. I agree with Benoit that this should be built at bootloader level, perhaps. Whatever you're doing in capebus, you could do at kernel space, build your DT bindings in runtime, and pass that DT blob to kernel. We're just passing the buck someplace else. We're not fixing the problem. What makes you think that dealing with this in the bootloader is going to be simpler? I never said it was supposed to be simpler, it just doesn't sound like something the kernel should care about. Kernel cares about the I just disagree here. The kernel should provide services that make the life of users easier, not the lives of the kernel developers easier. and it's already doing that isn't it ? we have i2c framework for i2c clients. From a userland point of view, you have input layer, iio, hwmon, chardev and a whole bunch of other interfaces which standardize device accesses. Look at your sentence again: kernel should make life of users easier, not that of kernel developers; IMHO capebus is just making it easier for the kernel developers who have to maintain a bunch of drivers for different devices on different capes ;-) At the end of the day, capebus will just be creating devices which will be handled by the same I2C framework, iio, input, hwmon, and so on. So what was the great benefit from capebus other than decreasing the amount of changes to .dts files ? One question though, what do you mean by some capes are full blown devices with their own drivers ? Do you mean you have capes running some other (RT)OS and communicating with linux somehow ? How does it communicate to the bone ? Some have FPGAs. https://specialcomp.com/beaglebone/BeagleBone_FPGA.html how does linux communicate with those ? What they are matters very little ;-) All we need is an interface to load binaries to the FPGA. We can not know what people will come up with. It might have a few GPIOs to load the bitfile to the FPGA, but after that, no-one can tell. I might not interface to Linux at all; it might interface via I2C, or RS232. which means that whoever writes RTL for the FPGA needs to do so with bone's I/O choices in mind. Let's assume the use UART to send bitfile to FPGA and bitfile is a model of an I2C Sensor, they'll have to use /dev/ttyOn to pass bitfile to FPGA and later an i2c-client driver (possibly using iio, since it's a sensor) will be loaded. Right ? Chances are, it won't fit in any kind of known drivers of linux. Some guy is using an FPGA for SDR, another is making a radar cape. awesome. That means we need to take care of those :-) Even with capebus, they will still have to write those drivers won't they ? So instead of writing some capebus driver, why can't the guy write a driver for his radar instead ? That way, if he ever turns that into an ASIC and decides to sell it as a chip, he doesn't have to write another driver just to strip the capebus away. These guys don't give a damn frankly about Linux. What they do care about is having a cheap/easy to develop platform for their own little widget. If you are going to ask from the to hunt down their own dts and assemble from various dtsi's they'll just move to something else. I never asked that :-) What I'm claiming is that capebus doesn't sound like the best solution for the problem exposed. Which is a shame, cause we do have a nice platform here. I agree with you, the bone is quite awesome ;-) Some capes have their own MCUs. A recent one has an 6502 communicating with uio_pruss. https://github.com/ohporter/b6502 that uses remoteproc, so I assume it's using OMAP's mailbox ? Again I say that this is not a 'capebus', it's just another device which we use another interface to talk to. i2c devices will be children of the omap i2c controller, spi devices will be children of the omap mcspi, GPMC devices will need the GPMC controller and so on, but none of this looks like argument to introduce a fake bus into the kernel. I'll let the users of said bus to do the talking. You're just flat out wrong IMO. fair enough, I feel the same way about your capebus ;-) -- balbi signature.asc Description: Digital signature
Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
Op 1 nov. 2012, om 14:06 heeft Felipe Balbi ba...@ti.com het volgende geschreven: Hi, On Thu, Nov 01, 2012 at 01:00:21PM +0100, Koen Kooi wrote: tl;dr: please suggest an actual solution that allows plugplay when plugging in multiple capes and applying power after that. Preferably one that doesn't pass the buck to u-boot. I can think of a few ways: 1) ship your distribution with all necessary drivers and let udev handle driver probing. clearly this will require constant updates for the distribution as new capes are developed. But IIUC, that's the same with Arduino where new libraries are added to the Arduino OS. And how are you going to handle pinmuxing and conflict resolution? You're basically saying that people should just use /dev/mem to write drivers, since you don't consider their use case valid. 2) ship with drivers for EEPROMs only and setup a repository of drivers this would require every driver to be packaged separately, then you create a setup where bone's userland will use EEPROMs data to figure out which drivers it needs, pass that information to SDK via USB, then SDK downloads all necessary/missing packages, sends them to bone via USB and all packages are installed on the bone. Note that since packages would be 'installed', this would be a one-time-only thing. I lack the words to describe my emotions after reading this. Let's leave it at that. 3) realize that if your user can build an FPGA cape, s/he can most likely write code and adding/recompiling kernel shouldn't be the biggest of his/her worries (no comments to this one, I understand it's not feasible) You'd be surprised. in any case, capebus sounds like something which is hugely unnecessary. On tablets and phones, yes. But TI chips are use for different use-cases, bone + capes being one of those. ps: at least for the I2C subsystem, i2c-core can detect for you if your driver provides -detect() method. So I just need to patch all i2c drivers and force people to use the standard address for the i2c chip when designing a board. Op 1 nov. 2012, om 12:26 heeft Cousson, Benoit b-cous...@ti.com het volgende geschreven: FWIW, we do have a similar, but simpler, problem with the beagle / beagle-xm and panda / panda-es. But for the moment we are just using a different DTS for each board. A different DTS for each board combination... There alot more capes for the bone that they are for the beagle the panda. And more are going to come, but not necessarily from people that have any connection to TI or CCO. Sure, but my point is that your solution will not solve our problem :-) This is a generic problem that you address with a very custom / specific approach. You still haven't described how I could solve the issue of conflicting capes using a single DTS. Well I don't have the solution otherwise I will have done it already :-) My point is that the solution has to be in the DT core if not in the bootloader. snarky commentSo when we at beagleboard.org handled the beagleboard and beagleboard xM expansionboards in the bootloader (detection, muxing, etc) we were told it was wrong and we should handle it in the kernel and if we waited a bit, DT would solve everything. And now that we actually handle it in the kernel you are saying that it is wrong and we should handle it in the bootloader and that DT won't solve everything. I guess someone will now tell us that uEFI will fix everything./snarky comment Apart from that, you and others still fail to tell us how you want to handle a user (or customer) that buys a beaglebone, an LCD cape, a weatherstation cape and a geiger counter cape and plugs those together and powers them on. With the evil TI vendor tree and extra patches the boardfile reads the eeproms and tries its best to instantiate all the platform data. One of the capes won't have working LEDs since appending to the leds-gpio struct is pretty much impossible in this couldn't you just instantiate multiple leds-gpio device ? No, and that is a problem in the driver core, see earlier discussions about similar problems. situation. But it gets a picture on the screen, blinks LEDs and does largely what the user expects. With capebus we get: 1) da8xx-fb which lacks DT bindingsp[1] receives plaftorm data to match the LCD this is something which could be fixed at the driver level, right ? :-) You'd have to tell your coworkers that. 2) the i2c sensors on the weathercape are registered that will work with or without capebus. Not in a plug and play way. 3) the one-wire bus on the weathercape gets registered also should work with or without capebus. Not in a plug and play way. 4) the LEDs on the lcd cape get registered5 also works with or without capebus. Not in a plug and play way. 5) the LED on the geigercape gets registered and adds
Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
Hi On Nov 1, 2012, at 3:16 PM, Felipe Balbi wrote: Hi, On Thu, Nov 01, 2012 at 02:57:26PM +0200, Pantelis Antoniou wrote: Each cape will have their own DTS and based on some board id you will fix the DT dynamically. My point is that the issue you are facing is a real limitation of DT, so you should fix the DT core and not workaround it by creating artificial bindings / drivers. You still haven't described any mechanism to deal with all the use cases I described. DT can't and will not deal with the complexity that we're facing right now. and DT-itself shouldn't. I agree with Benoit that this should be built at bootloader level, perhaps. Whatever you're doing in capebus, you could do at kernel space, build your DT bindings in runtime, and pass that DT blob to kernel. We're just passing the buck someplace else. We're not fixing the problem. What makes you think that dealing with this in the bootloader is going to be simpler? I never said it was supposed to be simpler, it just doesn't sound like something the kernel should care about. Kernel cares about the I just disagree here. The kernel should provide services that make the life of users easier, not the lives of the kernel developers easier. and it's already doing that isn't it ? we have i2c framework for i2c clients. From a userland point of view, you have input layer, iio, hwmon, chardev and a whole bunch of other interfaces which standardize device accesses. Look at your sentence again: kernel should make life of users easier, not that of kernel developers; IMHO capebus is just making it easier for the kernel developers who have to maintain a bunch of drivers for different devices on different capes ;-) At the end of the day, capebus will just be creating devices which will be handled by the same I2C framework, iio, input, hwmon, and so on. So what was the great benefit from capebus other than decreasing the amount of changes to .dts files ? How about true plug and play, conflict resolution real easy development of new cape designs. I fail to see how your convoluted method(s) fixes any of the above. And no passing the buck to someone else (be it u-boot, u-dev, user-space) won't cut it. What you are proposing will just stop dead all cape development besides the ones that dedicated teams at TI do. In fact the whole project, of a cheap Linux based, hackable community board will fail. One question though, what do you mean by some capes are full blown devices with their own drivers ? Do you mean you have capes running some other (RT)OS and communicating with linux somehow ? How does it communicate to the bone ? Some have FPGAs. https://specialcomp.com/beaglebone/BeagleBone_FPGA.html how does linux communicate with those ? What they are matters very little ;-) All we need is an interface to load binaries to the FPGA. We can not know what people will come up with. It might have a few GPIOs to load the bitfile to the FPGA, but after that, no-one can tell. I might not interface to Linux at all; it might interface via I2C, or RS232. which means that whoever writes RTL for the FPGA needs to do so with bone's I/O choices in mind. Let's assume the use UART to send bitfile to FPGA and bitfile is a model of an I2C Sensor, they'll have to use /dev/ttyOn to pass bitfile to FPGA and later an i2c-client driver (possibly using iio, since it's a sensor) will be loaded. Right ? No. I don't know details about what the actual cape design is, but they certainly don't want to deal with the piece-meal method, of loading one driver, and then creating a bunch of I2C devices, and then activating an RS232 tty, and then using that to burn the bitfile and so on. What they want, and what every user wants, is I plug this board in, and the driver make sure everything is loaded and ready. No, the end users don't want to see any of the implementation details of how the bitfile is transported; the driver can handle it. Chances are, it won't fit in any kind of known drivers of linux. Some guy is using an FPGA for SDR, another is making a radar cape. awesome. That means we need to take care of those :-) Even with capebus, they will still have to write those drivers won't they ? So instead of writing some capebus driver, why can't the guy write a driver for his radar instead ? That way, if he ever turns that into an ASIC and decides to sell it as a chip, he doesn't have to write another driver just to strip the capebus away. You have to build something working first, before you move on to make a custom board based to it. FWIW, after a design gets to work as a cape, chances are the hardware redesign will just end up with the same h/w connections as a cape, and just use an override to avoid putting the EEPROM in there. These guys don't give a damn frankly about Linux. What they do care about is having a cheap/easy to develop platform for their own little widget. If you are
Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
What they want, and what every user wants, is I plug this board in, and the driver make sure everything is loaded and ready. No, the end users don't want to see any of the implementation details of how the bitfile is transported; the driver can handle it. That doesn't necessarily make it a bus merely some kind of hotplug enumeration of devices. That should all work properly both for devices and busses with spi and i²c as the final bits needed for it got fixed some time ago. In an ideal world you don't want to be writing custom drivers for stuff. If your cape routes an i²c serial device to the existing system i²c busses then you want to just create an instance of any existing driver on the existing i²c bus not create a whole new layer of goop. It does need to do the plumbing and resource management for the plumbing but thats not the same as being a bus. 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
Re: [PATCH v3] ARM: dts: AM33xx: Add SPI node
Hi Avinash,
On 10/31/2012 11:51 AM, Philip, Avinash wrote:
Add McSPI data node to AM33XX device tree file. The McSPI module (and so
as the driver) is reused from OMAP4.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
Tested-by: Matt Porter mpor...@ti.com
I've just realized the interrupt-parent was still there, so I removed both.
Please find below the updated version.
Regards,
Benoit
From 9fd3c748aac9418cd377249ca463050783d2198f Mon Sep 17 00:00:00 2001
From: Philip, Avinash avinashphi...@ti.com
Date: Wed, 31 Oct 2012 16:21:09 +0530
Subject: [PATCH] ARM: dts: AM33XX: Add SPI node
Add McSPI data node to AM33XX device tree file. The McSPI module (and so
as the driver) is reused from OMAP4.
Signed-off-by: Philip, Avinash avinashphi...@ti.com
Tested-by: Matt Porter mpor...@ti.com
[b-cous...@ti.com: Remove interrupt-parent]
Signed-off-by: Benoit Cousson b-cous...@ti.com
---
arch/arm/boot/dts/am33xx.dtsi | 22 ++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 97a7bd3..5dfd682 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -299,5 +299,27 @@
76;
ti,hwmods = rtc;
};
+
+ spi0: spi@4803 {
+ compatible = ti,omap4-mcspi;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x4803 0x400;
+ interrupt = 65;
+ ti,spi-num-cs = 2;
+ ti,hwmods = spi0;
+ status = disabled;
+ };
+
+ spi1: spi@481a {
+ compatible = ti,omap4-mcspi;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0x481a 0x400;
+ interrupt = 125;
+ ti,spi-num-cs = 2;
+ ti,hwmods = spi1;
+ status = disabled;
+ };
};
};
--
1.7.0.4
--
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
Hi Alan, On Nov 1, 2012, at 3:51 PM, Alan Cox wrote: What they want, and what every user wants, is I plug this board in, and the driver make sure everything is loaded and ready. No, the end users don't want to see any of the implementation details of how the bitfile is transported; the driver can handle it. That doesn't necessarily make it a bus merely some kind of hotplug enumeration of devices. That should all work properly both for devices and busses with spi and i²c as the final bits needed for it got fixed some time ago. In an ideal world you don't want to be writing custom drivers for stuff. If your cape routes an i²c serial device to the existing system i²c busses then you want to just create an instance of any existing driver on the existing i²c bus not create a whole new layer of goop. It does need to do the plumbing and resource management for the plumbing but thats not the same as being a bus. Alan 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. 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. In a nutshell, no, I'm not writing any custom drivers for the stuff that exists already. There is no extra layer after the device is created and operates as it was located in the proper place in the DTS. The custom drivers are only needed for complex capes where you can't have the device simply work by creating the devices. Regards -- Pantelis -- 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: [PATCHv2] Input: omap4-keypad: Add pinctrl support
On Thu, Nov 1, 2012 at 1:07 PM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: On Thu, Nov 01, 2012 at 09:54:00AM +0100, Linus Walleij wrote: For the pin hogging I'd actually been thinking separately that we should just have the device core do a devm_pinctrl_get_set_default() prior to probing the device and store the result in the struct device. That would immediately remove almost all of the current pinctrl users, users that do need to do things with the data or check the result can then pick up the pinctrl pointer from the device struct. I never thought of that. This sounds like it would work. And the good thing is that this is a clean cut so we will centralized code without having to decide right now how to handle the pm idle/sleep cases. Talking here with Kevin Hilman on my left and Grant Likely on my right (they're physically here) there is some worry about stashing stuff into struct device. What if I retrieve this in the pinctrl subsystem using bus notifiers and then expose the struct pinctrl * to the clients by using pinctrl_get() and when you get such a handle in your probe() you know that the pinctrl subsystem has already fetched the handle and set it to default at that point? I just worry whether there is a fringe case where the default state is not be be default-selected in probe(), the API semantics does not mandate that. But I think this is the case for all in-kernel drivers so we wouldn't be breaking anything by doing this right now. And platforms can just leave the default state undefined in that case. It's actually something that needs to be acknowledged by the ARM SoC maintainers, because they will be the ones telling all subarch maintainers to go implement full PM handling with these three frameworks whenever an SoC driver want to handle pins. Well, they're going to have to implement it somewhere anyway - either in the drivers or in the SoC stuff. Sure I just worry about it being done is several different ways and creating a mess so they need to be involved to block other approaches. I can surely fix these for my systems, but it really needs to be enforced widely or it will be a mess. We definitely need to decide if it's something that should be open coded everywhere. If I prepare a patch to move the fetch+set defaul to the pinctrl core using notifiers, we centralize one piece and we get the currently floating patches out of the way. Then what to do with sleep and idle is a question we need to handle next. Requiring PM domains for this is one approach, albeit a bit controversial. Yours, Linus Walleij -- 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: [PATCHv2] Input: omap4-keypad: Add pinctrl support
On Thu, Nov 01, 2012 at 03:01:28PM +0100, Linus Walleij wrote: On Thu, Nov 1, 2012 at 1:07 PM, Mark Brown For the pin hogging I'd actually been thinking separately that we should just have the device core do a devm_pinctrl_get_set_default() prior to probing the device and store the result in the struct device. That What if I retrieve this in the pinctrl subsystem using bus notifiers and then expose the struct pinctrl * to the clients by using pinctrl_get() and when you get such a handle in your probe() you know that the pinctrl subsystem has already fetched the handle and set it to default at that point? I'm not sure I parse a problem from the above? I just worry whether there is a fringe case where the default state is not be be default-selected in probe(), the API semantics does not mandate that. But I think this is the case for all in-kernel drivers so we wouldn't be breaking anything by doing this right now. And platforms can just leave the default state undefined in that case. Yes, that had been my thinking too though I'd really expect that the platform ought to be able to think of something sensible to do by default. Then what to do with sleep and idle is a question we need to handle next. Requiring PM domains for this is one approach, albeit a bit controversial. Yup. Notifiers are another option again I guess. There's far fewer drivers doing anything at all with that so it's a bit less urgent. signature.asc Description: Digital signature
Re: [PATCH 2/3] da8xx-dt: Create da8xx DT adapter device
On 2012-11-01 17:18, Pantelis Antoniou wrote:
omap_device is going private.
Move the da8xx-dt adapter device to arch/arm/mach-omap2.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
+
+ /* display_panel */
+ priv-lcd_panel.panel_type = QVGA;
+ priv-lcd_panel.max_bpp = 16;
+ priv-lcd_panel.min_bpp = 16;
+ priv-lcd_panel.panel_shade = COLOR_ACTIVE;
+
+ /* lcd_ctrl_config */
+ priv-lcd_cfg.p_disp_panel = priv-lcd_panel;
+ priv-lcd_cfg.ac_bias = 255;
+ priv-lcd_cfg.ac_bias_intrpt= 0;
+ priv-lcd_cfg.dma_burst_sz = 16;
+ priv-lcd_cfg.bpp = 16;
+ priv-lcd_cfg.fdd = 0x80;
+ priv-lcd_cfg.tft_alt_mode = 0;
+ priv-lcd_cfg.stn_565_mode = 0;
+ priv-lcd_cfg.mono_8bit_mode= 0;
+ priv-lcd_cfg.invert_line_clock = 1;
+ priv-lcd_cfg.invert_frm_clock = 1;
+ priv-lcd_cfg.sync_edge = 0;
+ priv-lcd_cfg.sync_ctrl = 1;
+ priv-lcd_cfg.raster_order = 0;
+
+ /* da8xx_lcdc_platform_data */
+ strcpy(priv-lcd_pdata.manu_name, BBToys);
+ priv-lcd_pdata.controller_data = priv-lcd_cfg;
+ strcpy(priv-lcd_pdata.type, panel_type);
+
+ priv-lcdc_oh = omap_hwmod_lookup(lcdc);
+ if (priv-lcdc_oh == NULL) {
+ dev_err(pdev-dev, Failed to lookup omap_hwmod lcdc\n);
+ return -ENODEV;
+ }
+
+ priv-lcdc_pdev = omap_device_build(da8xx_lcdc, 0, priv-lcdc_oh,
+ priv-lcd_pdata,
+ sizeof(struct da8xx_lcdc_platform_data),
+ NULL, 0, 0);
+ if (priv-lcdc_pdev == NULL) {
+ dev_err(pdev-dev, Failed to build LCDC device\n);
+ return -ENODEV;
+ }
I know nothing about BeagleBone, da8xx_lcdc, or the capes, but here are
my thoughts... =)
If I understood this cape-thing correctly, to handle the LCDs properly
the da8xx_lcdc driver should be changed to be more dynamic.
The da8xx_lcdc device should be always added by the standard SoC code.
If the LCD panel is fixed for the board in question, the lcdc could be
passed the LCD data as done now (I guess).
But in beaglebone's case the platform data for lcdc should be empty, and
the lcdc driver should do just minimal setup, like memmapping its
registers. No pinmuxing nor other such things.
When the cape is identified and the cape's driver is loaded, the driver
would configure lcdc depending on the cape, including pinmuxing. After
that the LCD should be functional.
Tomi
--
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 2/3] da8xx-dt: Create da8xx DT adapter device
Hi Tomi,
On Nov 1, 2012, at 4:36 PM, Tomi Valkeinen wrote:
On 2012-11-01 17:18, Pantelis Antoniou wrote:
omap_device is going private.
Move the da8xx-dt adapter device to arch/arm/mach-omap2.
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
+
+/* display_panel */
+priv-lcd_panel.panel_type = QVGA;
+priv-lcd_panel.max_bpp = 16;
+priv-lcd_panel.min_bpp = 16;
+priv-lcd_panel.panel_shade = COLOR_ACTIVE;
+
+/* lcd_ctrl_config */
+priv-lcd_cfg.p_disp_panel = priv-lcd_panel;
+priv-lcd_cfg.ac_bias = 255;
+priv-lcd_cfg.ac_bias_intrpt= 0;
+priv-lcd_cfg.dma_burst_sz = 16;
+priv-lcd_cfg.bpp = 16;
+priv-lcd_cfg.fdd = 0x80;
+priv-lcd_cfg.tft_alt_mode = 0;
+priv-lcd_cfg.stn_565_mode = 0;
+priv-lcd_cfg.mono_8bit_mode= 0;
+priv-lcd_cfg.invert_line_clock = 1;
+priv-lcd_cfg.invert_frm_clock = 1;
+priv-lcd_cfg.sync_edge = 0;
+priv-lcd_cfg.sync_ctrl = 1;
+priv-lcd_cfg.raster_order = 0;
+
+/* da8xx_lcdc_platform_data */
+strcpy(priv-lcd_pdata.manu_name, BBToys);
+priv-lcd_pdata.controller_data = priv-lcd_cfg;
+strcpy(priv-lcd_pdata.type, panel_type);
+
+priv-lcdc_oh = omap_hwmod_lookup(lcdc);
+if (priv-lcdc_oh == NULL) {
+dev_err(pdev-dev, Failed to lookup omap_hwmod lcdc\n);
+return -ENODEV;
+}
+
+priv-lcdc_pdev = omap_device_build(da8xx_lcdc, 0, priv-lcdc_oh,
+priv-lcd_pdata,
+sizeof(struct da8xx_lcdc_platform_data),
+NULL, 0, 0);
+if (priv-lcdc_pdev == NULL) {
+dev_err(pdev-dev, Failed to build LCDC device\n);
+return -ENODEV;
+}
I know nothing about BeagleBone, da8xx_lcdc, or the capes, but here are
my thoughts... =)
If I understood this cape-thing correctly, to handle the LCDs properly
the da8xx_lcdc driver should be changed to be more dynamic.
The da8xx_lcdc device should be always added by the standard SoC code.
If the LCD panel is fixed for the board in question, the lcdc could be
passed the LCD data as done now (I guess).
But in beaglebone's case the platform data for lcdc should be empty, and
the lcdc driver should do just minimal setup, like memmapping its
registers. No pinmuxing nor other such things.
When the cape is identified and the cape's driver is loaded, the driver
would configure lcdc depending on the cape, including pinmuxing. After
that the LCD should be functional.
Tomi
You are absolutely correct. That's the proper way to go about it,
but you go to war with the drivers you have, and not the drivers you wish
you had :)
Meaning, it is getting fixed by the da8xx maintainers, but it's not ready yet.
The da8xx-dt can die a short and merciful death then.
Regards
-- Pantelis--
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: [RESEND PATCH 05/11] ARM: OMAP: USB: Host: usb host Device tree node Adaptation
From: Balbi, Felipe
Sent: Thursday, November 01, 2012 3:51 PM
To: Munegowda, Keshava
Cc: Tony Lindgren; linux-omap@vger.kernel.org;
devicetree-disc...@lists.ozlabs.org; linux-...@vger.kernel.org;
linux-...@vger.kernel.org; Balbi, Felipe; sa...@linux.intel.com; Cousson, Benoit
Subject: Re: [RESEND PATCH 05/11] ARM: OMAP: USB: Host: usb host Device tree
node Adaptation
On Thu, Nov 01, 2012 at 09:19:48AM +0100, Munegowda, Keshava wrote:
From: Tony Lindgren [t...@atomide.com]
Sent: Wednesday, October 31, 2012 11:59 PM
To: Munegowda, Keshava
Cc: linux-omap@vger.kernel.org; devicetree-disc...@lists.ozlabs.org;
linux-...@vger.kernel.org; linux-...@vger.kernel.org; Balbi, Felipe;
sa...@linux.intel.com; Cousson, Benoit
Subject: Re: [RESEND PATCH 05/11] ARM: OMAP: USB: Host: usb host Device tree
node Adaptation
* Keshava Munegowda keshava_mgo...@ti.com [121031 07:29]:
The USB2 Host device node is extracted and used in the probe
of the driver to initialize the usb ports and controller. The
platform specific initialization is also performed.
Signed-off-by: Keshava Munegowda keshava_mgo...@ti.com
---
arch/arm/mach-omap2/usb-host.c |2 -
drivers/mfd/omap-usb-host.c| 163
+++-
include/linux/platform_data/usb-omap.h | 19 +++-
3 files changed, 133 insertions(+), 51 deletions(-)
diff --git a/arch/arm/mach-omap2/usb-host.c b/arch/arm/mach-omap2/usb-host.c
index d1dbe12..239c175 100644
--- a/arch/arm/mach-omap2/usb-host.c
+++ b/arch/arm/mach-omap2/usb-host.c
@@ -502,8 +502,6 @@ void __init usbhs_init(const struct
usbhs_omap_board_data *pdata)
}
ehci_data.phy_reset = pdata-phy_reset;
ohci_data.es2_compatibility = pdata-es2_compatibility;
- usbhs_data.ehci_data = ehci_data;
- usbhs_data.ohci_data = ohci_data;
if (cpu_is_omap34xx()) {
setup_ehci_io_mux(pdata-port_mode);
Just checking.. Have you tested that these patches also
still work without device tree?
Regards,
Tony
No ! with out device tree enabled , these patches does not work.
do I need to make a code such way that it works with and without
device tree..?
yes. OMAP3/4 still have lots of legacy platform_data-only board support
;-)
Thanks Felipe.
I will do this.
regards
keshava
--
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
[PATCH 0/3] ARM: dts: OMAP4/5 device-tree timer updates
A few device tree timer updates for OMAP4/5 devices. This series adds ... 1. MPU private addresses for OMAP4 timers 2. Timer nodes for OMAP5 3. 32kHz counter node for OMAP5 This is based upon of Benoit Cousson's OMAP device-tree branch for v3.8. git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.8/dts Jon Hunter (3): ARM: dts: Update OMAP4 timer addresses ARM: dts: Add OMAP5 timer nodes ARM: dts: Add OMAP5 counter node arch/arm/boot/dts/omap4.dtsi | 20 + arch/arm/boot/dts/omap5.dtsi | 95 ++ 2 files changed, 107 insertions(+), 8 deletions(-) -- 1.7.9.5 -- 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
[PATCH 1/3] ARM: dts: Update OMAP4 timer addresses
For OMAP4 devices, timers 5-8 have both a L3 bus address and a Cortex-A9
private bus address. Currently the device-tree source only contains the
L3 bus address for these timers. Update these timers to include the
Cortex-A9 private address and make the default address the Cortex-A9
private bus address to match the current HWMOD implementation.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/omap4.dtsi | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index 23ee149..739bb79 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -469,33 +469,37 @@
ti,hwmods = timer4;
};
- timer5: timer@49038000 {
+ timer5: timer@40138000 {
compatible = ti,omap2-timer;
- reg = 0x49038000 0x80;
+ reg = 0x40138000 0x80,
+ 0x49038000 0x80;
interrupts = 0 41 0x4;
ti,hwmods = timer5;
ti,timer-dsp;
};
- timer6: timer@4903a000 {
+ timer6: timer@4013a000 {
compatible = ti,omap2-timer;
- reg = 0x4903a000 0x80;
+ reg = 0x4013a000 0x80,
+ 0x4903a000 0x80;
interrupts = 0 42 0x4;
ti,hwmods = timer6;
ti,timer-dsp;
};
- timer7: timer@4903c000 {
+ timer7: timer@4013c000 {
compatible = ti,omap2-timer;
- reg = 0x4903c000 0x80;
+ reg = 0x4013c000 0x80,
+ 0x4903c000 0x80;
interrupts = 0 43 0x4;
ti,hwmods = timer7;
ti,timer-dsp;
};
- timer8: timer@4903e000 {
+ timer8: timer@4013e000 {
compatible = ti,omap2-timer;
- reg = 0x4903e000 0x80;
+ reg = 0x4013e000 0x80,
+ 0x4903e000 0x80;
interrupts = 0 44 0x4;
ti,hwmods = timer8;
ti,timer-pwm;
--
1.7.9.5
--
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
[PATCH 2/3] ARM: dts: Add OMAP5 timer nodes
Add the 11 timer nodes for OMAP5 devices.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/omap5.dtsi | 89 ++
1 file changed, 89 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index 930dbfe..c8954f1 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -379,5 +379,94 @@
ti,buffer-size = 128;
ti,hwmods = mcbsp3;
};
+
+ timer1: timer@4ae18000 {
+ compatible = ti,omap2-timer;
+ reg = 0x4ae18000 0x80;
+ interrupts = 0 37 0x4;
+ ti,hwmods = timer1;
+ ti,timer-alwon;
+ };
+
+ timer2: timer@48032000 {
+ compatible = ti,omap2-timer;
+ reg = 0x48032000 0x80;
+ interrupts = 0 38 0x4;
+ ti,hwmods = timer2;
+ };
+
+ timer3: timer@48034000 {
+ compatible = ti,omap2-timer;
+ reg = 0x48034000 0x80;
+ interrupts = 0 39 0x4;
+ ti,hwmods = timer3;
+ };
+
+ timer4: timer@48036000 {
+ compatible = ti,omap2-timer;
+ reg = 0x48036000 0x80;
+ interrupts = 0 40 0x4;
+ ti,hwmods = timer4;
+ };
+
+ timer5: timer@40138000 {
+ compatible = ti,omap2-timer;
+ reg = 0x40138000 0x80,
+ 0x49038000 0x80;
+ interrupts = 0 41 0x4;
+ ti,hwmods = timer5;
+ ti,timer-dsp;
+ };
+
+ timer6: timer@4013a000 {
+ compatible = ti,omap2-timer;
+ reg = 0x4013a000 0x80,
+ 0x4903a000 0x80;
+ interrupts = 0 42 0x4;
+ ti,hwmods = timer6;
+ ti,timer-dsp;
+ ti,timer-pwm;
+ };
+
+ timer7: timer@4013c000 {
+ compatible = ti,omap2-timer;
+ reg = 0x4013c000 0x80,
+ 0x4903c000 0x80;
+ interrupts = 0 43 0x4;
+ ti,hwmods = timer7;
+ ti,timer-dsp;
+ };
+
+ timer8: timer@4013e000 {
+ compatible = ti,omap2-timer;
+ reg = 0x4013e000 0x80,
+ 0x4903e000 0x80;
+ interrupts = 0 44 0x4;
+ ti,hwmods = timer8;
+ ti,timer-dsp;
+ ti,timer-pwm;
+ };
+
+ timer9: timer@4803e000 {
+ compatible = ti,omap2-timer;
+ reg = 0x4803e000 0x80;
+ interrupts = 0 45 0x4;
+ ti,hwmods = timer9;
+ };
+
+ timer10: timer@48086000 {
+ compatible = ti,omap2-timer;
+ reg = 0x48086000 0x80;
+ interrupts = 0 46 0x4;
+ ti,hwmods = timer10;
+ };
+
+ timer11: timer@48088000 {
+ compatible = ti,omap2-timer;
+ reg = 0x48088000 0x80;
+ interrupts = 0 47 0x4;
+ ti,hwmods = timer11;
+ ti,timer-pwm;
+ };
};
};
--
1.7.9.5
--
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
[PATCH 3/3] ARM: dts: Add OMAP5 counter node
Add the 32kHz counter node for OMAP5 devices.
Signed-off-by: Jon Hunter jon-hun...@ti.com
---
arch/arm/boot/dts/omap5.dtsi |6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi
index c8954f1..ead74c8 100644
--- a/arch/arm/boot/dts/omap5.dtsi
+++ b/arch/arm/boot/dts/omap5.dtsi
@@ -77,6 +77,12 @@
ranges;
ti,hwmods = l3_main_1, l3_main_2, l3_main_3;
+ counter32k: counter@4ae04000 {
+ compatible = ti,omap-counter32k;
+ reg = 0x4ae04000 0x40;
+ ti,hwmods = counter_32k;
+ };
+
omap5_pmx_core: pinmux@4a002840 {
compatible = ti,omap4-padconf, pinctrl-single;
reg = 0x4a002840 0x01b6;
--
1.7.9.5
--
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: OMAP baseline test results for v3.7-rc3
On 31/10/12 14:24, Mark Jackson wrote: On 31/10/12 13:57, Hiremath, Vaibhav wrote: On Wed, Oct 31, 2012 at 19:11:03, Mark Jackson wrote: If I try the latest mainline U-Boot (or the TI branch), I just get to Starting kernel ... and then hangs. I am using Mainline u-boot and it works for me. Can you paste u-boot boot log and environment variable here? mainline U-Boot boot log U-Boot SPL 2012.10-00434-ged296d2 (Oct 31 2012 - 14:18:50) OMAP SD/MMC: 0 reading u-boot.img reading u-boot.img U-Boot 2012.10-00434-ged296d2 (Oct 31 2012 - 14:18:50) I2C: ready DRAM: 256 MiB WARNING: Caches not enabled MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Using default environment Net: cpsw Hit any key to stop autoboot: 0 mmc0 is current device SD/MMC found on device 0 reading uEnv.txt 29 bytes read Loaded environment from uEnv.txt Importing environment from mmc ... 4315695 bytes read Booting from mmc ... ## Booting kernel from Legacy Image at 8020 ... Image Name: Linux-3.7.0-rc1-47802-ge7289dc-d Image Type: ARM Linux Kernel Image (uncompressed) Data Size:4308448 Bytes = 4.1 MiB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK Loading Kernel Image ... OK OK Starting kernel ... Contents of uEnv.txt mmcrootfstype=ext2 rootwait Vaibhav Does this boot log shed any light on my non-boot problem ? Are we using the same U-Boot version (2012.10-00434-ged296d2) ? Can you post your linux-ohporter .config ? I was also thinking, if the previously mentioned patch [1] was concerning toolchains, what toolchain are you using ? I'm using the latest mainline Buildroot git, which compiles gcc version 4.5.4 (Buildroot 2012.11-git-00497-ge48bf89). [1] - http://www.spinics.net/lists/linux-omap/msg79911.html Cheers Mark J. -- 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] ARM: dts: OMAP4/5 device-tree timer updates
Hi Jon, On 11/01/2012 04:49 PM, Jon Hunter wrote: A few device tree timer updates for OMAP4/5 devices. This series adds ... 1. MPU private addresses for OMAP4 timers 2. Timer nodes for OMAP5 3. 32kHz counter node for OMAP5 Great, thanks for that update. Just in time before the pull request. This is based upon of Benoit Cousson's OMAP device-tree branch for v3.8. git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.8/dts Jon Hunter (3): ARM: dts: Update OMAP4 timer addresses ARM: dts: Add OMAP5 timer nodes ARM: dts: Add OMAP5 counter node I've just updated slightly the subjects: 3b3132f ARM: dts: OMAP5: Add counter node df692a9 ARM: dts: OMAP5: Add timer nodes d03a93b ARM: dts: OMAP4: Update timer addresses There are now in my for_3.8/dts branch. Thanks, Benoit -- 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] ARM: OMAP4: ID: Improve features detection and check
On 11/01/2012 01:35 PM, Santosh Shilimkar wrote:
On Thursday 01 November 2012 03:53 PM, Ivan Khoronzhuk wrote:
Replaces several flags bearing the same meaning. There is no need
to set flags due to different omap types here, it can be checked
in appropriate places as well.
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
arch/arm/mach-omap2/id.c | 25 +++--
arch/arm/mach-omap2/soc.h |8 ++--
2 files changed, 9 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index cf2362c..3c47a19 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -28,6 +28,9 @@
#include soc.h
#include control.h
+#define OMAP4_SILICON_TYPE_STANDARD0x01
+#define OMAP4_SILICON_TYPE_PERFORMANCE0x02
+
static unsigned int omap_revision;
static const char *cpu_rev;
u32 omap_features;
@@ -273,25 +276,11 @@ void __init omap4xxx_check_features(void)
{
u32 si_type;
-if (cpu_is_omap443x())
-omap_features |= OMAP4_HAS_MPU_1GHZ;
-
+si_type =
+(read_tap_reg(OMAP4_CTRL_MODULE_CORE_STD_FUSE_PROD_ID_1) 16)
0x03;
-if (cpu_is_omap446x()) {
-si_type =
- read_tap_reg(OMAP4_CTRL_MODULE_CORE_STD_FUSE_PROD_ID_1);
-switch ((si_type (3 16)) 16) {
-case 2:
-/* High performance device */
-omap_features |= OMAP4_HAS_MPU_1_5GHZ;
-break;
-case 1:
-default:
-/* Standard device */
-omap_features |= OMAP4_HAS_MPU_1_2GHZ;
-break;
-}
-}
+if (si_type == OMAP4_SILICON_TYPE_PERFORMANCE)
+omap_features = OMAP4_HAS_PERF_SILICON;
Well the detection isn't for performance/standard but there are some
features depend on it. For example 1 GHz doesn't DPLL DCC enable feature
where as 1.2 GHz, 1.5 GHz doesn't need. This is the main reason this
information is also effused. Have you considered this aspect while
creating this patch ?
Regards
Santosh
I had considered it. There is no dependency on the features.
DCC usage depends on asked frequency on the fly, not from the features.
Depending on performance/standard feature the available frequencies
should be chosen in places where they are needed, for example while
initializing OPPs.
Currently we have several features while it is only one indeed.
--
Regards,
Ivan Khoronzhuk
--
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] ARM: OMAP4: ID: Improve features detection and check
On Thursday 01 November 2012 09:50 PM, ivan.khoronzhuk wrote:
On 11/01/2012 01:35 PM, Santosh Shilimkar wrote:
On Thursday 01 November 2012 03:53 PM, Ivan Khoronzhuk wrote:
Replaces several flags bearing the same meaning. There is no need
to set flags due to different omap types here, it can be checked
in appropriate places as well.
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
arch/arm/mach-omap2/id.c | 25 +++--
arch/arm/mach-omap2/soc.h |8 ++--
2 files changed, 9 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index cf2362c..3c47a19 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -28,6 +28,9 @@
#include soc.h
#include control.h
+#define OMAP4_SILICON_TYPE_STANDARD0x01
+#define OMAP4_SILICON_TYPE_PERFORMANCE0x02
+
static unsigned int omap_revision;
static const char *cpu_rev;
u32 omap_features;
@@ -273,25 +276,11 @@ void __init omap4xxx_check_features(void)
{
u32 si_type;
-if (cpu_is_omap443x())
-omap_features |= OMAP4_HAS_MPU_1GHZ;
-
+si_type =
+(read_tap_reg(OMAP4_CTRL_MODULE_CORE_STD_FUSE_PROD_ID_1) 16)
0x03;
-if (cpu_is_omap446x()) {
-si_type =
- read_tap_reg(OMAP4_CTRL_MODULE_CORE_STD_FUSE_PROD_ID_1);
-switch ((si_type (3 16)) 16) {
-case 2:
-/* High performance device */
-omap_features |= OMAP4_HAS_MPU_1_5GHZ;
-break;
-case 1:
-default:
-/* Standard device */
-omap_features |= OMAP4_HAS_MPU_1_2GHZ;
-break;
-}
-}
+if (si_type == OMAP4_SILICON_TYPE_PERFORMANCE)
+omap_features = OMAP4_HAS_PERF_SILICON;
Well the detection isn't for performance/standard but there are some
features depend on it. For example 1 GHz doesn't DPLL DCC enable feature
where as 1.2 GHz, 1.5 GHz doesn't need. This is the main reason this
information is also effused. Have you considered this aspect while
creating this patch ?
Regards
Santosh
I had considered it. There is no dependency on the features.
DCC usage depends on asked frequency on the fly, not from the features.
Depending on performance/standard feature the available frequencies
should be chosen in places where they are needed, for example while
initializing OPPs.
You are correct about the way DCC is handled in the clock code. Infact
all these features like L2CACHE, SGX, IVA etc is more for to display
boot messages.
Currently we have several features while it is only one indeed.
1GHz, 1.2GHz, 1.5 GHz are not same since the silicon capability itself
is different.
git blame tells me that Nishant has sent this update so looping him
if above differentiation in boot log helps.
Nishant,
What's your take on removing above freq prints and marking
those silicon as performance silicons as the $subject patch does ?
Regards
Santosh
--
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] ARM: OMAP4: ID: Improve features detection and check
On 22:05-20121101, Santosh Shilimkar wrote:
On Thursday 01 November 2012 09:50 PM, ivan.khoronzhuk wrote:
On 11/01/2012 01:35 PM, Santosh Shilimkar wrote:
On Thursday 01 November 2012 03:53 PM, Ivan Khoronzhuk wrote:
Replaces several flags bearing the same meaning. There is no need
to set flags due to different omap types here, it can be checked
in appropriate places as well.
Cc: Tony Lindgren t...@atomide.com
Cc: Russell King li...@arm.linux.org.uk
Cc: linux-omap@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com
---
arch/arm/mach-omap2/id.c | 25 +++--
arch/arm/mach-omap2/soc.h |8 ++--
2 files changed, 9 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/id.c b/arch/arm/mach-omap2/id.c
index cf2362c..3c47a19 100644
--- a/arch/arm/mach-omap2/id.c
+++ b/arch/arm/mach-omap2/id.c
@@ -28,6 +28,9 @@
#include soc.h
#include control.h
+#define OMAP4_SILICON_TYPE_STANDARD0x01
+#define OMAP4_SILICON_TYPE_PERFORMANCE0x02
+
static unsigned int omap_revision;
static const char *cpu_rev;
u32 omap_features;
@@ -273,25 +276,11 @@ void __init omap4xxx_check_features(void)
{
u32 si_type;
-if (cpu_is_omap443x())
-omap_features |= OMAP4_HAS_MPU_1GHZ;
-
+si_type =
+(read_tap_reg(OMAP4_CTRL_MODULE_CORE_STD_FUSE_PROD_ID_1) 16)
0x03;
-if (cpu_is_omap446x()) {
-si_type =
- read_tap_reg(OMAP4_CTRL_MODULE_CORE_STD_FUSE_PROD_ID_1);
-switch ((si_type (3 16)) 16) {
-case 2:
-/* High performance device */
-omap_features |= OMAP4_HAS_MPU_1_5GHZ;
-break;
-case 1:
-default:
-/* Standard device */
-omap_features |= OMAP4_HAS_MPU_1_2GHZ;
-break;
-}
-}
+if (si_type == OMAP4_SILICON_TYPE_PERFORMANCE)
+omap_features = OMAP4_HAS_PERF_SILICON;
Well the detection isn't for performance/standard but there are some
features depend on it. For example 1 GHz doesn't DPLL DCC enable feature
where as 1.2 GHz, 1.5 GHz doesn't need. This is the main reason this
information is also effused. Have you considered this aspect while
creating this patch ?
Regards
Santosh
I had considered it. There is no dependency on the features.
DCC usage depends on asked frequency on the fly, not from the features.
Depending on performance/standard feature the available frequencies
should be chosen in places where they are needed, for example while
initializing OPPs.
You are correct about the way DCC is handled in the clock code. Infact
all these features like L2CACHE, SGX, IVA etc is more for to display
boot messages.
Currently we have several features while it is only one indeed.
1GHz, 1.2GHz, 1.5 GHz are not same since the silicon capability itself
is different.
git blame tells me that Nishant has sent this update so looping him
if above differentiation in boot log helps.
Nishant,
What's your take on removing above freq prints and marking
those silicon as performance silicons as the $subject patch does ?
Regards
Santosh
Yes $subject patch is a better approach compared to having freq based
handling which just increases the number of macros we need to enable
depending on SoC variants that we spin off the main SoC. This also
allows us to conserve the features bitfield ahead as well.
I hate to admit, but after a couple of generations of SoC spinoffs,
my original logic is proving to be was pretty short sighted,
unfortunately :(
So, approach
Acked-by: Nishanth Menon n...@ti.com
--
Regards,
Nishanth Menon
--
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
[GIT PULL] ARM: OMAP: DTS for 3.8
Hi Tony,
Please pull some more OMAP5 and AM33xx data for 3.8.
The branch contains as well some cleanup and the omap3-beagle support since the
previous one was in fact a beagle-xm.
Thanks,
Benoit
The following changes since commit 8f0d8163b50e01f398b14bcd4dc039ac5ab18d64:
Linus Torvalds (1):
Linux 3.7-rc3
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git
for_3.8/dts
Afzal Mohammed (1):
ARM: dts: AM33XX: Add rtc node
AnilKumar Ch (8):
ARM: dts: AM33XX: Add device tree OPP table
ARM: dts: AM33XX: Add basic pinctrl device tree data
ARM: dts: AM33XX: Add D_CAN device tree data
ARM: dts: AM33XX: Add lis331dlh device tree data to am335x-evm
ARM: dts: AM33XX: Add temperature sensor device tree data to am335x-evm
ARM: dts: AM33XX: Add tsl2550 ambient light sensor DT data
ARM: dts: Add am335x-evmsk.dts
Documentation: dt: i2c: Update trivial-devices list
Benoit Cousson (2):
ARM: dts: OMAP: Move interrupt-parent to the root node to avoid
duplication
ARM: dts: OMAP: Rename pandaES and var_som for consistency
Jon Hunter (6):
ARM: dts: Add omap3-beagle.dts
ARM: dts: OMAP: Add timer nodes
ARM: dts: OMAP: Add counter-32k nodes
ARM: dts: OMAP4: Update timer addresses
ARM: dts: OMAP5: Add timer nodes
ARM: dts: OMAP5: Add counter node
Kishon Vijay Abraham I (3):
ARM: dts: Add twl6030-usb data
ARM: dts: Add twl4030-usb data
ARM: dts: OMAP4: add *reg* property for ocp2scp
Philip, Avinash (1):
ARM: dts: AM33XX: Add SPI node
Sebastien Guiriec (4):
ARM: dts: omap5: Update GPIO with address space and interrupts
ARM: dts: omap5: Update I2C with address space and interrupts
ARM: dts: omap5: Update UART with address space and interrupts
ARM: dts: omap5: Update MMC with address space and interrupts
.../devicetree/bindings/arm/omap/counter.txt | 15 ++
.../devicetree/bindings/arm/omap/timer.txt | 31
.../devicetree/bindings/bus/omap-ocp2scp.txt | 18 ++
.../devicetree/bindings/i2c/trivial-devices.txt|2 +
arch/arm/boot/dts/Makefile |5 +-
arch/arm/boot/dts/am335x-bone.dts |6 +
arch/arm/boot/dts/am335x-evm.dts | 55 +++
arch/arm/boot/dts/am335x-evmsk.dts | 166
arch/arm/boot/dts/am33xx.dtsi | 139 +++--
arch/arm/boot/dts/omap2.dtsi | 86 ++
arch/arm/boot/dts/omap2420.dtsi| 16 ++-
arch/arm/boot/dts/omap2430.dtsi| 19 ++-
arch/arm/boot/dts/omap3-beagle-xm.dts |6 -
arch/arm/boot/dts/omap3-beagle.dts | 67
arch/arm/boot/dts/omap3.dtsi | 107 -
.../dts/{omap4-pandaES.dts = omap4-panda-es.dts} |0
arch/arm/boot/dts/omap4-panda.dts |4 +
arch/arm/boot/dts/omap4-sdp.dts|4 +
.../dts/{omap4-var_som.dts = omap4-var-som.dts} |0
arch/arm/boot/dts/omap4.dtsi | 105 -
arch/arm/boot/dts/omap5.dtsi | 156 +-
arch/arm/boot/dts/twl4030.dtsi | 27 +++
arch/arm/boot/dts/twl6030.dtsi |5 +
23 files changed, 989 insertions(+), 50 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/omap/counter.txt
create mode 100644 Documentation/devicetree/bindings/arm/omap/timer.txt
create mode 100644 arch/arm/boot/dts/am335x-evmsk.dts
create mode 100644 arch/arm/boot/dts/omap3-beagle.dts
rename arch/arm/boot/dts/{omap4-pandaES.dts = omap4-panda-es.dts} (100%)
rename arch/arm/boot/dts/{omap4-var_som.dts = omap4-var-som.dts} (100%)
--
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] ARM: OMAP4: ID: Improve features detection and check
On Thursday 01 November 2012 10:36 PM, Nishanth Menon wrote: On 22:05-20121101, Santosh Shilimkar wrote: On Thursday 01 November 2012 09:50 PM, ivan.khoronzhuk wrote: On 11/01/2012 01:35 PM, Santosh Shilimkar wrote: On Thursday 01 November 2012 03:53 PM, Ivan Khoronzhuk wrote: Replaces several flags bearing the same meaning. There is no need to set flags due to different omap types here, it can be checked in appropriate places as well. Cc: Tony Lindgren t...@atomide.com Cc: Russell King li...@arm.linux.org.uk Cc: linux-omap@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Ivan Khoronzhuk ivan.khoronz...@ti.com --- [..] +if (si_type == OMAP4_SILICON_TYPE_PERFORMANCE) +omap_features = OMAP4_HAS_PERF_SILICON; Well the detection isn't for performance/standard but there are some features depend on it. For example 1 GHz doesn't DPLL DCC enable feature where as 1.2 GHz, 1.5 GHz doesn't need. This is the main reason this information is also effused. Have you considered this aspect while creating this patch ? Regards Santosh I had considered it. There is no dependency on the features. DCC usage depends on asked frequency on the fly, not from the features. Depending on performance/standard feature the available frequencies should be chosen in places where they are needed, for example while initializing OPPs. You are correct about the way DCC is handled in the clock code. Infact all these features like L2CACHE, SGX, IVA etc is more for to display boot messages. Currently we have several features while it is only one indeed. 1GHz, 1.2GHz, 1.5 GHz are not same since the silicon capability itself is different. git blame tells me that Nishant has sent this update so looping him if above differentiation in boot log helps. Nishant, What's your take on removing above freq prints and marking those silicon as performance silicons as the $subject patch does ? Regards Santosh Yes $subject patch is a better approach compared to having freq based handling which just increases the number of macros we need to enable depending on SoC variants that we spin off the main SoC. This also allows us to conserve the features bitfield ahead as well. I hate to admit, but after a couple of generations of SoC spinoffs, my original logic is proving to be was pretty short sighted, unfortunately :( So, approach Acked-by: Nishanth Menon n...@ti.com Thanks Nishant for clarification and ack. With the clarification I also like the subject patch. Feel free add. Acked-by: Santosh Shilimkar santosh.shilim...@ti.com -- 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
[PATCH v2 0/4] RFC: OMAP GPMC DT bindings
This is a series of patches to support GPMC peripherals on OMAP boards. Depends on Linus' master + omap-next (branch omap-for-v3.8/cleanup-headers-gpmc) The only supported peripheral for now is NAND, but other types would be easy to add. Version 2 addresses details pointed out by Jon Hunter, Afzal Mohammed and Rob Herring: - add reg and ti,hwmod properties to Documentation - use generic of_mtd functions and the property names defined by them, namely nand-bus-width and nand-ecc-mode - reduce the default register space size in the Documentation to 8K, as found in the hwmod code - switch to a DT layout based on ranges and address translation. Although this property is not currently looked at as long as the handling code still uses the runtime calculation methods, we now have these values in the bindings, eventually allowing us to switch the implementation with less pain. Thanks, Daniel Daniel Mack (4): mtd: omap-nand: pass device_node in platform data ARM: OMAP: gpmc: enable hwecc for AM33xx SoCs ARM: OMAP: gpmc: don't create devices from initcall on DT ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND Documentation/devicetree/bindings/bus/ti-gpmc.txt | 73 +++ .../devicetree/bindings/mtd/gpmc-nand.txt | 61 + arch/arm/mach-omap2/gpmc-nand.c| 2 +- arch/arm/mach-omap2/gpmc.c | 146 + drivers/mtd/nand/omap2.c | 4 +- include/linux/platform_data/mtd-nand-omap2.h | 2 + 6 files changed, 286 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/bus/ti-gpmc.txt create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nand.txt -- 1.7.11.7 -- 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
[PATCH v2 1/4] mtd: omap-nand: pass device_node in platform data
Pass an optional device_node pointer in the platform data, which in turn
will be put into a mtd_part_parser_data. This way, code that sets up the
platform devices can pass along the node from DT so that the partitions
can be parsed.
For non-DT boards, this change has no effect.
Signed-off-by: Daniel Mack zon...@gmail.com
---
drivers/mtd/nand/omap2.c | 4 +++-
include/linux/platform_data/mtd-nand-omap2.h | 2 ++
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
index 3282b15..a733f15 100644
--- a/drivers/mtd/nand/omap2.c
+++ b/drivers/mtd/nand/omap2.c
@@ -1331,6 +1331,7 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
dma_cap_mask_t mask;
unsigned sig;
struct resource *res;
+ struct mtd_part_parser_data ppdata = {};
pdata = pdev-dev.platform_data;
if (pdata == NULL) {
@@ -1556,7 +1557,8 @@ static int __devinit omap_nand_probe(struct
platform_device *pdev)
goto out_release_mem_region;
}
- mtd_device_parse_register(info-mtd, NULL, NULL, pdata-parts,
+ ppdata.of_node = pdata-of_node;
+ mtd_device_parse_register(info-mtd, NULL, ppdata, pdata-parts,
pdata-nr_parts);
platform_set_drvdata(pdev, info-mtd);
diff --git a/include/linux/platform_data/mtd-nand-omap2.h
b/include/linux/platform_data/mtd-nand-omap2.h
index 24d32ca..5217d6e 100644
--- a/include/linux/platform_data/mtd-nand-omap2.h
+++ b/include/linux/platform_data/mtd-nand-omap2.h
@@ -60,6 +60,8 @@ struct omap_nand_platform_data {
int devsize;
enum omap_ecc ecc_opt;
struct gpmc_nand_regs reg;
+ /* for passing the partitions */
+ struct device_node *of_node;
};
#endif
--
1.7.11.7
--
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
[PATCH v2 2/4] ARM: OMAP: gpmc: enable hwecc for AM33xx SoCs
Signed-off-by: Daniel Mack zon...@gmail.com
---
arch/arm/mach-omap2/gpmc-nand.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/gpmc-nand.c b/arch/arm/mach-omap2/gpmc-nand.c
index 8607735..c3616c6 100644
--- a/arch/arm/mach-omap2/gpmc-nand.c
+++ b/arch/arm/mach-omap2/gpmc-nand.c
@@ -92,7 +92,7 @@ static int omap2_nand_gpmc_retime(
static bool __init gpmc_hwecc_bch_capable(enum omap_ecc ecc_opt)
{
/* support only OMAP3 class */
- if (!cpu_is_omap34xx()) {
+ if (!cpu_is_omap34xx() !soc_is_am33xx()) {
pr_err(BCH ecc is not supported on this CPU\n);
return 0;
}
--
1.7.11.7
--
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
[PATCH v2 3/4] ARM: OMAP: gpmc: don't create devices from initcall on DT
On DT driven boards, the gpmc node will match the driver. Hence, there's
no need to do that unconditionally from the initcall.
Signed-off-by: Daniel Mack zon...@gmail.com
---
arch/arm/mach-omap2/gpmc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/mach-omap2/gpmc.c b/arch/arm/mach-omap2/gpmc.c
index 60f1cce..1dcb30c 100644
--- a/arch/arm/mach-omap2/gpmc.c
+++ b/arch/arm/mach-omap2/gpmc.c
@@ -844,6 +844,13 @@ static int __init omap_gpmc_init(void)
struct platform_device *pdev;
char *oh_name = gpmc;
+ /*
+* if the board boots up with a populated DT, do not
+* manually add the device from this initcall
+*/
+ if (of_have_populated_dt())
+ return -ENODEV;
+
oh = omap_hwmod_lookup(oh_name);
if (!oh) {
pr_err(Could not look up %s\n, oh_name);
--
1.7.11.7
--
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
[PATCH v2 4/4] ARM: OMAP: gpmc: add DT bindings for GPMC timings and NAND
This patch adds basic DT bindings for OMAP GPMC.
The actual peripherals are instanciated from child nodes within the GPMC
node, and the only type of device that is currently supported is NAND.
Code was added to parse the generic GPMC timing parameters and some
documentation with examples on how to use them.
Successfully tested on an AM33xx board.
Signed-off-by: Daniel Mack zon...@gmail.com
---
Documentation/devicetree/bindings/bus/ti-gpmc.txt | 73 +++
.../devicetree/bindings/mtd/gpmc-nand.txt | 61 +
arch/arm/mach-omap2/gpmc.c | 139 +
3 files changed, 273 insertions(+)
create mode 100644 Documentation/devicetree/bindings/bus/ti-gpmc.txt
create mode 100644 Documentation/devicetree/bindings/mtd/gpmc-nand.txt
diff --git a/Documentation/devicetree/bindings/bus/ti-gpmc.txt
b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
new file mode 100644
index 000..6f44487
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/ti-gpmc.txt
@@ -0,0 +1,73 @@
+Device tree bindings for OMAP general purpose memory controllers (GPMC)
+
+The actual devices are instantiated from the child nodes of a GPMC node.
+
+Required properties:
+
+ - compatible: Should be set to ti,gpmc
+ - reg:A resource specifier for the register space
+ (see the example below)
+ - ti,hwmods: Should be set to ti,gpmc until the DT transition is
+ completed.
+ - #address-cells: Must be set to 2 to allow memory address translation
+ - #size-cells:Must be set to 1 to allow CS address passing
+ - ranges: Must be set up to reflect the memory layout
+ Note that this property is not currently parsed.
+ Calculated values derived from the contents of
+ GPMC_CS_CONFIG7 as set up by the bootloader. That will
+ change in the future, so be sure to fill the correct
+ values here.
+
+Timing properties for child nodes. All are optional and default to 0.
+
+ - gpmc,sync-clk: Minimum clock period for synchronous mode, in
picoseconds
+
+ Chip-select signal timings corresponding to GPMC_CS_CONFIG2:
+ - gpmc,cs-on: Assertion time
+ - gpmc,cs-rd-off: Read deassertion time
+ - gpmc,cs-wr-off: Write deassertion time
+
+ ADV signal timings corresponding to GPMC_CONFIG3:
+ - gpmc,adv-on:Assertion time
+ - gpmc,adv-rd-off:Read deassertion time
+ - gpmc,adv-wr-off:Write deassertion time
+
+ WE signals timings corresponding to GPMC_CONFIG4:
+ - gpmc,we-on: Assertion time
+ - gpmc,we-off:Deassertion time
+
+ OE signals timings corresponding to GPMC_CONFIG4
+ - gpmc,oe-on: Assertion time
+ - gpmc,oe-off:Deassertion time
+
+ Access time and cycle time timings corresponding to GPMC_CONFIG5
+ - gpmc,page-burst-access: Multiple access word delay
+ - gpmc,access:Start-cycle to first data valid delay
+ - gpmc,rd-cycle: Total read cycle time
+ - gpmc,wr-cycle: Total write cycle time
+
+The following are only on OMAP3430
+ - gpmc,wr-access
+ - gpmc,wr-data-mux-bus
+
+
+Example for an AM33xx board:
+
+ gpmc: gpmc@5000 {
+ compatible = ti,gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x5000 0x2000;
+ interrupt-parent = intc;
+ interrupts = 100;
+
+ #address-cells = 2;
+ #size-cells = 1;
+ ranges = 0 0 0x0800 0x1000; /* CS0 */
+
+ /* child nodes go here */
+ };
+
+
+
+
+
diff --git a/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
new file mode 100644
index 000..e0c1e67
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/gpmc-nand.txt
@@ -0,0 +1,61 @@
+Device tree bindings for GPMC connected NANDs
+
+GPMC connected NAND (found on OMAP boards) are represented as child nodes of
+the GPMC controller with a name of nand.
+
+All timing relevant properties as well as generic gpmc child properties are
+explained in a separate documents - please refer to
+Documentation/devicetree/bindings/bus/ti-gpmc.txt
+
+For NAND specific properties such as ECC modes or bus width, please refer to
+Documentation/devicetree/bindings/mtd/nand.txt
+
+
+Required properties:
+
+ - reg: The CS line the peripheral is connected to
+
+For inline partiton table parsing (optional):
+
+ - #address-cells: should be set to 1
+ - #size-cells: should be set to 1
+
+Example for an AM33xx board:
+
+ gpmc: gpmc@5000 {
+ compatible = ti,gpmc;
+ ti,hwmods = gpmc;
+ reg = 0x5000 0x100;
+ interrupt-parent = intc;
+ interrupts = 100;
+ #address-cells = 2;
+ #size-cells = 1;
+
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: [PATCH 0/3] capebus moving omap_devices to mach-omap2
* Jason Kridner jkrid...@beagleboard.org [121101 11:52]: 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. Having it all behave like a hotpluggable bus makes sense. But the way to sort it out is to have all the omap internal devices defined in a .dts file and have them set initially with status = disabled in the .dts. Then you just need a function dynamically change the kernel internal device tree to enable and disable devices dynamically so the dev entries get created and driver probe can happen. Sure that means that some hwmod and omap_device functions can't be __init any longer, but there should not be any need to call hwmod and omap_device functions directly from capebus. If you want to take it one step further, you can also add new capes to the kernel internal device tree dynamically as you may have different pinmux and omap internal device configurations on the capes. 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
[PATCH v3 0/4] cbus/retu drivers
This patch set introduces drivers for CBUS access and Retu multifunction chip found on Nokia Internet Tablets (770, N800, N810). It would be nice get these patches applied as the functionality of these devices is severely lacking without Retu. E.g. watchdog support is mandatory at least on Nokia N800, you cannot currently run the mainline kernel for longer than ~60 seconds (there is no way to disable the watchdog). Drivers originate from linux-omap cbus branch and have been cleaned up/rewritten around i2c and MFD core. Patches have been tested on top of 3.7-rc3 with Nokia N800 (watchdog feeding works, power off shuts down the device, power button triggers IRQs and input events, loading and unloading retu-pwrbutton module in a loop while manically pressing the power button does not crash the kernel). Changes since the second version (https://lkml.org/lkml/2012/10/31/520): - i2c-cbus: - move i2c-cbus.h under linux/platform_data - retu-mfd - replace retu_pwrbutton_res[0] expression with simpler retu_pwrbutton_res. - retu-pwrbutton: - eliminate struct retu_pwrbutton - delete checks for duplicate events - rework probe to avoid races - disable IRQ before unregister in retu_pwrbutton_remove() to avoid races - eliminate double free in retu_pwrbutton_remove() - add .owner = THIS_MODULE Changes since the first version (https://lkml.org/lkml/2012/9/3/265): - i2c-cbus: - use devres - improve comments - simplify and delete redundant code - refactoring bug fixes on error handling - discard input parameter from cbus_send_bit/data() - retu-mfd: - use devres - use regmap - retu_wdt: use devres - retu-pwrbutton: use devres Changes since the RFC version (http://marc.info/?l=linux-omapm=134618967116737w=2): - added DT support for getting i2c-cbus GPIO pins - merged n8x0 board file changes into i2c-cbus patch - corrected typo in Kconfig for MFD_RETU - added power off functionality to retu-mfd - added IRQ functionality to retu-mfd - added power button key driver - some cleanups Aaro Koskinen (4): i2c: introduce i2c-cbus driver mfd: introduce retu-mfd driver watchdog: introduce retu_wdt driver input: misc: introduce retu-pwrbutton arch/arm/mach-omap2/board-n8x0.c | 42 + drivers/i2c/busses/Kconfig | 10 + drivers/i2c/busses/Makefile|1 + drivers/i2c/busses/i2c-cbus.c | 300 drivers/input/misc/Kconfig | 10 + drivers/input/misc/Makefile|1 + drivers/input/misc/retu-pwrbutton.c| 102 +++ drivers/mfd/Kconfig|9 + drivers/mfd/Makefile |1 + drivers/mfd/retu-mfd.c | 264 drivers/watchdog/Kconfig | 12 ++ drivers/watchdog/Makefile |1 + drivers/watchdog/retu_wdt.c| 178 +++ include/linux/mfd/retu.h | 22 +++ include/linux/platform_data/i2c-cbus.h | 27 +++ 15 files changed, 980 insertions(+), 0 deletions(-) create mode 100644 drivers/i2c/busses/i2c-cbus.c create mode 100644 drivers/input/misc/retu-pwrbutton.c create mode 100644 drivers/mfd/retu-mfd.c create mode 100644 drivers/watchdog/retu_wdt.c create mode 100644 include/linux/mfd/retu.h create mode 100644 include/linux/platform_data/i2c-cbus.h -- 1.7.2.5 -- 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
[PATCH v3 2/4] mfd: introduce retu-mfd driver
Retu is a multi-function device found on Nokia Internet Tablets
implementing at least watchdog, RTC, headset detection and power button
functionality.
This patch implements minimum functionality providing register access,
IRQ handling and power off functions.
Cc: sa...@linux.intel.com
Acked-by: Felipe Balbi ba...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
drivers/mfd/Kconfig |9 ++
drivers/mfd/Makefile |1 +
drivers/mfd/retu-mfd.c | 264 ++
include/linux/mfd/retu.h | 22
4 files changed, 296 insertions(+), 0 deletions(-)
create mode 100644 drivers/mfd/retu-mfd.c
create mode 100644 include/linux/mfd/retu.h
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index acab3ef..7528c5e 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -1044,6 +1044,15 @@ config MFD_PALMAS
If you say yes here you get support for the Palmas
series of PMIC chips from Texas Instruments.
+config MFD_RETU
+ tristate Support for Retu multi-function device
+ select MFD_CORE
+ depends on I2C
+ select REGMAP_IRQ
+ help
+ Retu is a multi-function device found on Nokia Internet Tablets
+ (770, N800 and N810).
+
endmenu
endif
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index d8ccb63..ad7879f 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -138,3 +138,4 @@ obj-$(CONFIG_MFD_RC5T583) += rc5t583.o rc5t583-irq.o
obj-$(CONFIG_MFD_SEC_CORE) += sec-core.o sec-irq.o
obj-$(CONFIG_MFD_SYSCON) += syscon.o
obj-$(CONFIG_MFD_LM3533) += lm3533-core.o lm3533-ctrlbank.o
+obj-$(CONFIG_MFD_RETU) += retu-mfd.o
diff --git a/drivers/mfd/retu-mfd.c b/drivers/mfd/retu-mfd.c
new file mode 100644
index 000..7ff4a37
--- /dev/null
+++ b/drivers/mfd/retu-mfd.c
@@ -0,0 +1,264 @@
+/*
+ * Retu MFD driver
+ *
+ * Copyright (C) 2004, 2005 Nokia Corporation
+ *
+ * Based on code written by Juha Yrjölä, David Weinehall and Mikko Ylinen.
+ * Rewritten by Aaro Koskinen.
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file COPYING in the main directory of this
+ * archive for more details.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/err.h
+#include linux/i2c.h
+#include linux/irq.h
+#include linux/init.h
+#include linux/slab.h
+#include linux/mutex.h
+#include linux/module.h
+#include linux/regmap.h
+#include linux/mfd/core.h
+#include linux/mfd/retu.h
+#include linux/interrupt.h
+#include linux/moduleparam.h
+
+/* Registers */
+#define RETU_REG_ASICR 0x00/* ASIC ID and revision */
+#define RETU_REG_ASICR_VILMA (1 7)/* Bit indicating Vilma */
+#define RETU_REG_IDR 0x01/* Interrupt ID */
+#define RETU_REG_IMR 0x02/* Interrupt mask */
+
+/* Interrupt sources */
+#define RETU_INT_PWR 0 /* Power button */
+
+struct retu_dev {
+ struct regmap *regmap;
+ struct device *dev;
+ struct mutexmutex;
+ struct regmap_irq_chip_data *irq_data;
+};
+
+static struct resource retu_pwrbutton_res[] = {
+ {
+ .name = retu-pwrbutton,
+ .start = RETU_INT_PWR,
+ .end= RETU_INT_PWR,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+static struct mfd_cell retu_devs[] = {
+ {
+ .name = retu-wdt
+ },
+ {
+ .name = retu-pwrbutton,
+ .resources = retu_pwrbutton_res,
+ .num_resources = ARRAY_SIZE(retu_pwrbutton_res),
+ }
+};
+
+static struct regmap_irq retu_irqs[] = {
+ [RETU_INT_PWR] = {
+ .mask = 1 RETU_INT_PWR,
+ }
+};
+
+static struct regmap_irq_chip retu_irq_chip = {
+ .name = RETU,
+ .irqs = retu_irqs,
+ .num_irqs = ARRAY_SIZE(retu_irqs),
+ .num_regs = 1,
+ .status_base= RETU_REG_IDR,
+ .mask_base = RETU_REG_IMR,
+ .ack_base = RETU_REG_IDR,
+};
+
+/* Retu device registered for the power off. */
+static struct retu_dev *retu_pm_power_off;
+
+int retu_read(struct retu_dev *rdev, u8 reg)
+{
+ int ret;
+ int value;
+
+ mutex_lock(rdev-mutex);
+ ret = regmap_read(rdev-regmap, reg, value);
+ mutex_unlock(rdev-mutex);
+
+ return ret ? ret : value;
+}
+EXPORT_SYMBOL_GPL(retu_read);
+
+int retu_write(struct retu_dev *rdev, u8 reg, u16 data)
+{
+ int ret;
+
+ mutex_lock(rdev-mutex);
+ ret = regmap_write(rdev-regmap, reg, data);
+
[PATCH v3 1/4] i2c: introduce i2c-cbus driver
Add i2c driver to enable access to devices behind CBUS on Nokia Internet
Tablets.
The patch also adds CBUS I2C configuration for N8x0 which is one of the
users of this driver.
Cc: linux-...@vger.kernel.org
Acked-by: Felipe Balbi ba...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
arch/arm/mach-omap2/board-n8x0.c | 42 +
drivers/i2c/busses/Kconfig | 10 +
drivers/i2c/busses/Makefile|1 +
drivers/i2c/busses/i2c-cbus.c | 300
include/linux/platform_data/i2c-cbus.h | 27 +++
5 files changed, 380 insertions(+), 0 deletions(-)
create mode 100644 drivers/i2c/busses/i2c-cbus.c
create mode 100644 include/linux/platform_data/i2c-cbus.h
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index d95f727..8e8a09d 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -16,10 +16,12 @@
#include linux/gpio.h
#include linux/init.h
#include linux/io.h
+#include linux/irq.h
#include linux/stddef.h
#include linux/i2c.h
#include linux/spi/spi.h
#include linux/usb/musb.h
+#include linux/platform_data/i2c-cbus.h
#include linux/platform_data/spi-omap2-mcspi.h
#include linux/platform_data/mtd-onenand-omap2.h
#include sound/tlv320aic3x.h
@@ -39,6 +41,45 @@
#define TUSB6010_GPIO_ENABLE 0
#define TUSB6010_DMACHAN 0x3f
+#if defined(CONFIG_I2C_CBUS) || defined(CONFIG_I2C_CBUS_MODULE)
+static struct i2c_cbus_platform_data n8x0_cbus_data = {
+ .clk_gpio = 66,
+ .dat_gpio = 65,
+ .sel_gpio = 64,
+};
+
+static struct platform_device n8x0_cbus_device = {
+ .name = i2c-cbus,
+ .id = 3,
+ .dev= {
+ .platform_data = n8x0_cbus_data,
+ },
+};
+
+static struct i2c_board_info n8x0_i2c_board_info_3[] __initdata = {
+ {
+ I2C_BOARD_INFO(retu-mfd, 0x01),
+ },
+};
+
+static void __init n8x0_cbus_init(void)
+{
+ const int retu_irq_gpio = 108;
+
+ if (gpio_request_one(retu_irq_gpio, GPIOF_IN, Retu IRQ))
+ return;
+ irq_set_irq_type(gpio_to_irq(retu_irq_gpio), IRQ_TYPE_EDGE_RISING);
+ n8x0_i2c_board_info_3[0].irq = gpio_to_irq(retu_irq_gpio);
+ i2c_register_board_info(3, n8x0_i2c_board_info_3,
+ ARRAY_SIZE(n8x0_i2c_board_info_3));
+ platform_device_register(n8x0_cbus_device);
+}
+#else /* CONFIG_I2C_CBUS */
+static void __init n8x0_cbus_init(void)
+{
+}
+#endif /* CONFIG_I2C_CBUS */
+
#if defined(CONFIG_USB_MUSB_TUSB6010) ||
defined(CONFIG_USB_MUSB_TUSB6010_MODULE)
/*
* Enable or disable power to TUSB6010. When enabling, turn on 3.3 V and
@@ -677,6 +718,7 @@ static void __init n8x0_init_machine(void)
gpmc_onenand_init(board_onenand_data);
n8x0_mmc_init();
n8x0_usb_init();
+ n8x0_cbus_init();
}
MACHINE_START(NOKIA_N800, Nokia N800)
diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 65dd599..d01c8ef 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -338,6 +338,16 @@ config I2C_BLACKFIN_TWI_CLK_KHZ
help
The unit of the TWI clock is kHz.
+config I2C_CBUS
+ tristate CBUS I2C driver
+ depends on GENERIC_GPIO
+ help
+ Support for CBUS access using I2C API. Mostly relevant for Nokia
+ Internet Tablets (770, N800 and N810).
+
+ This driver can also be built as a module. If so, the module
+ will be called i2c-cbus.
+
config I2C_CPM
tristate Freescale CPM1 or CPM2 (MPC8xx/826x)
depends on (CPM1 || CPM2) OF_I2C
diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile
index 2d33d62..3c548b1 100644
--- a/drivers/i2c/busses/Makefile
+++ b/drivers/i2c/busses/Makefile
@@ -31,6 +31,7 @@ obj-$(CONFIG_I2C_POWERMAC)+= i2c-powermac.o
obj-$(CONFIG_I2C_AT91) += i2c-at91.o
obj-$(CONFIG_I2C_AU1550) += i2c-au1550.o
obj-$(CONFIG_I2C_BLACKFIN_TWI) += i2c-bfin-twi.o
+obj-$(CONFIG_I2C_CBUS) += i2c-cbus.o
obj-$(CONFIG_I2C_CPM) += i2c-cpm.o
obj-$(CONFIG_I2C_DAVINCI) += i2c-davinci.o
obj-$(CONFIG_I2C_DESIGNWARE_CORE) += i2c-designware-core.o
diff --git a/drivers/i2c/busses/i2c-cbus.c b/drivers/i2c/busses/i2c-cbus.c
new file mode 100644
index 000..e6086cf
--- /dev/null
+++ b/drivers/i2c/busses/i2c-cbus.c
@@ -0,0 +1,300 @@
+/*
+ * CBUS I2C driver for Nokia Internet Tablets.
+ *
+ * Copyright (C) 2004-2010 Nokia Corporation
+ *
+ * Based on code written by Juha Yrjölä, David Weinehall, Mikko Ylinen and
+ * Felipe Balbi. Converted to I2C driver by Aaro Koskinen.
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file COPYING in the main directory of this
+ * archive for more details.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the
[PATCH v3 4/4] input: misc: introduce retu-pwrbutton
Add Retu power button driver.
Cc: linux-in...@vger.kernel.org
Acked-by: Felipe Balbi ba...@ti.com
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
drivers/input/misc/Kconfig | 10
drivers/input/misc/Makefile |1 +
drivers/input/misc/retu-pwrbutton.c | 102 +++
3 files changed, 113 insertions(+), 0 deletions(-)
create mode 100644 drivers/input/misc/retu-pwrbutton.c
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 7c0f1ec..e5be189 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -367,6 +367,16 @@ config INPUT_CM109
To compile this driver as a module, choose M here: the module will be
called cm109.
+config INPUT_RETU_PWRBUTTON
+ tristate Retu Power button Driver
+ depends on MFD_RETU
+ help
+ Say Y here if you want to enable power key reporting via the
+ Retu chips found in Nokia Internet Tablets (770, N800, N810).
+
+ To compile this driver as a module, choose M here. The module will
+ be called retu-pwrbutton.
+
config INPUT_TWL4030_PWRBUTTON
tristate TWL4030 Power button Driver
depends on TWL4030_CORE
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 83fe6f5..4fbee0d 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_INPUT_PMIC8XXX_PWRKEY) += pmic8xxx-pwrkey.o
obj-$(CONFIG_INPUT_POWERMATE) += powermate.o
obj-$(CONFIG_INPUT_PWM_BEEPER) += pwm-beeper.o
obj-$(CONFIG_INPUT_RB532_BUTTON) += rb532_button.o
+obj-$(CONFIG_INPUT_RETU_PWRBUTTON) += retu-pwrbutton.o
obj-$(CONFIG_INPUT_GPIO_ROTARY_ENCODER)+= rotary_encoder.o
obj-$(CONFIG_INPUT_SGI_BTNS) += sgi_btns.o
obj-$(CONFIG_INPUT_SPARCSPKR) += sparcspkr.o
diff --git a/drivers/input/misc/retu-pwrbutton.c
b/drivers/input/misc/retu-pwrbutton.c
new file mode 100644
index 000..043a12b
--- /dev/null
+++ b/drivers/input/misc/retu-pwrbutton.c
@@ -0,0 +1,102 @@
+/*
+ * Retu power button driver.
+ *
+ * Copyright (C) 2004-2010 Nokia Corporation
+ *
+ * Original code written by Ari Saastamoinen, Juha Yrjölä and Felipe Balbi.
+ * Rewritten by Aaro Koskinen.
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file COPYING in the main directory of this
+ * archive for more details.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/irq.h
+#include linux/init.h
+#include linux/slab.h
+#include linux/errno.h
+#include linux/input.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/mfd/retu.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+
+#define RETU_STATUS_PWRONX (1 5)
+
+static irqreturn_t retu_pwrbutton_irq(int irq, void *_pwr)
+{
+ bool state;
+ struct input_dev *idev = _pwr;
+ struct retu_dev *rdev = input_get_drvdata(idev);
+
+ state = !(retu_read(rdev, RETU_REG_STATUS) RETU_STATUS_PWRONX);
+ input_report_key(idev, KEY_POWER, state);
+ input_sync(idev);
+
+ return IRQ_HANDLED;
+}
+
+static int __devinit retu_pwrbutton_probe(struct platform_device *pdev)
+{
+ struct retu_dev *rdev = dev_get_drvdata(pdev-dev.parent);
+ struct input_dev *idev;
+ int ret;
+
+ idev = input_allocate_device();
+ if (!idev)
+ return -ENOMEM;
+
+ idev-evbit[0] = BIT_MASK(EV_KEY);
+ idev-keybit[BIT_WORD(KEY_POWER)] = BIT_MASK(KEY_POWER);
+ idev-name = retu-pwrbutton;
+
+ platform_set_drvdata(pdev, idev);
+ input_set_drvdata(idev, rdev);
+
+ ret = input_register_device(idev);
+ if (ret 0) {
+ input_free_device(idev);
+ return ret;
+ }
+
+ ret = devm_request_threaded_irq(pdev-dev, platform_get_irq(pdev, 0),
+ NULL, retu_pwrbutton_irq, 0,
+ retu-pwrbutton, idev);
+ if (ret 0)
+ input_unregister_device(idev);
+
+ return ret;
+}
+
+static int __devexit retu_pwrbutton_remove(struct platform_device *pdev)
+{
+ struct input_dev *idev = platform_get_drvdata(pdev);
+
+ disable_irq(platform_get_irq(pdev, 0));
+ input_unregister_device(idev);
+
+ return 0;
+}
+
+static struct platform_driver retu_pwrbutton_driver = {
+ .probe = retu_pwrbutton_probe,
+ .remove = __devexit_p(retu_pwrbutton_remove),
+ .driver = {
+ .name = retu-pwrbutton,
+ .owner = THIS_MODULE,
+ },
+};
+module_platform_driver(retu_pwrbutton_driver);
+
[PATCH v3 3/4] watchdog: introduce retu_wdt driver
Introduce Retu watchdog driver.
Cc: linux-watch...@vger.kernel.org
Acked-by: Felipe Balbi ba...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
Signed-off-by: Aaro Koskinen aaro.koski...@iki.fi
---
drivers/watchdog/Kconfig| 12 +++
drivers/watchdog/Makefile |1 +
drivers/watchdog/retu_wdt.c | 178 +++
3 files changed, 191 insertions(+), 0 deletions(-)
create mode 100644 drivers/watchdog/retu_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index ad1bb93..c3a836d 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -352,6 +352,18 @@ config IMX2_WDT
To compile this driver as a module, choose M here: the
module will be called imx2_wdt.
+config RETU_WATCHDOG
+ tristate Retu watchdog
+ depends on MFD_RETU
+ select WATCHDOG_CORE
+ help
+ Retu watchdog driver for Nokia Internet Tablets (700, N800,
+ N810). At least on N800 the watchdog cannot be disabled, so
+ this driver is essential and you should enable it.
+
+ To compile this driver as a module, choose M here: the
+ module will be called retu_wdt.
+
# AVR32 Architecture
config AT32AP700X_WDT
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 572b39b..d2f1c0c 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -52,6 +52,7 @@ obj-$(CONFIG_STMP3XXX_WATCHDOG) += stmp3xxx_wdt.o
obj-$(CONFIG_NUC900_WATCHDOG) += nuc900_wdt.o
obj-$(CONFIG_TS72XX_WATCHDOG) += ts72xx_wdt.o
obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o
+obj-$(CONFIG_RETU_WATCHDOG) += retu_wdt.o
# AVR32 Architecture
obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
diff --git a/drivers/watchdog/retu_wdt.c b/drivers/watchdog/retu_wdt.c
new file mode 100644
index 000..aeb0f39
--- /dev/null
+++ b/drivers/watchdog/retu_wdt.c
@@ -0,0 +1,178 @@
+/*
+ * Retu watchdog driver
+ *
+ * Copyright (C) 2004, 2005 Nokia Corporation
+ *
+ * Based on code written by Amit Kucheria and Michael Buesch.
+ * Rewritten by Aaro Koskinen.
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file COPYING in the main directory of this
+ * archive for more details.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/init.h
+#include linux/slab.h
+#include linux/errno.h
+#include linux/device.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/mfd/retu.h
+#include linux/watchdog.h
+#include linux/platform_device.h
+
+/* Watchdog timer values in seconds */
+#define RETU_WDT_MAX_TIMER 63
+
+struct retu_wdt_dev {
+ struct retu_dev *rdev;
+ struct device *dev;
+ struct delayed_work ping_work;
+};
+
+/*
+ * Since Retu watchdog cannot be disabled in hardware, we must kick it
+ * with a timer until userspace watchdog software takes over. If
+ * CONFIG_WATCHDOG_NOWAYOUT is set, we never start the feeding.
+ */
+static void retu_wdt_ping_enable(struct retu_wdt_dev *wdev)
+{
+ retu_write(wdev-rdev, RETU_REG_WATCHDOG, RETU_WDT_MAX_TIMER);
+ schedule_delayed_work(wdev-ping_work,
+ round_jiffies_relative(RETU_WDT_MAX_TIMER * HZ / 2));
+}
+
+static void retu_wdt_ping_disable(struct retu_wdt_dev *wdev)
+{
+ retu_write(wdev-rdev, RETU_REG_WATCHDOG, RETU_WDT_MAX_TIMER);
+ cancel_delayed_work_sync(wdev-ping_work);
+}
+
+static void retu_wdt_ping_work(struct work_struct *work)
+{
+ struct retu_wdt_dev *wdev = container_of(to_delayed_work(work),
+ struct retu_wdt_dev, ping_work);
+ retu_wdt_ping_enable(wdev);
+}
+
+static int retu_wdt_start(struct watchdog_device *wdog)
+{
+ struct retu_wdt_dev *wdev = watchdog_get_drvdata(wdog);
+
+ retu_wdt_ping_disable(wdev);
+
+ return retu_write(wdev-rdev, RETU_REG_WATCHDOG, wdog-timeout);
+}
+
+static int retu_wdt_stop(struct watchdog_device *wdog)
+{
+ struct retu_wdt_dev *wdev = watchdog_get_drvdata(wdog);
+
+ retu_wdt_ping_enable(wdev);
+
+ return 0;
+}
+
+static int retu_wdt_ping(struct watchdog_device *wdog)
+{
+ struct retu_wdt_dev *wdev = watchdog_get_drvdata(wdog);
+
+ return retu_write(wdev-rdev, RETU_REG_WATCHDOG, wdog-timeout);
+}
+
+static int retu_wdt_set_timeout(struct watchdog_device *wdog,
+ unsigned int timeout)
+{
+ struct retu_wdt_dev *wdev = watchdog_get_drvdata(wdog);
+
+ wdog-timeout = timeout;
+ return retu_write(wdev-rdev, RETU_REG_WATCHDOG, wdog-timeout);
+}
+
+static const struct watchdog_info retu_wdt_info = {
+ .options = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING,
+ .identity = Retu watchdog,
+};
+
+static const struct
Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
HI, On Thu, Nov 01, 2012 at 03:59:50PM +0200, Pantelis Antoniou wrote: Hi Alan, On Nov 1, 2012, at 3:51 PM, Alan Cox wrote: What they want, and what every user wants, is I plug this board in, and the driver make sure everything is loaded and ready. No, the end users don't want to see any of the implementation details of how the bitfile is transported; the driver can handle it. That doesn't necessarily make it a bus merely some kind of hotplug enumeration of devices. That should all work properly both for devices and busses with spi and i²c as the final bits needed for it got fixed some time ago. In an ideal world you don't want to be writing custom drivers for stuff. If your cape routes an i²c serial device to the existing system i²c busses then you want to just create an instance of any existing driver on the existing i²c bus not create a whole new layer of goop. It does need to do the plumbing and resource management for the plumbing but thats not the same as being a bus. Alan 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. 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. -- balbi signature.asc Description: Digital signature
Re: [PATCH] i2c: omap: ensure writes to dev-buf_len are ordered
On Thu, Oct 25, 2012 at 12:00:48PM +0300, Felipe Balbi wrote: if we allow compiler reorder our writes, we could fall into a situation where dev-buf_len is reset for no apparent reason. This bug was found with a simple script which would transfer data to an i2c client from 1 to 1024 bytes (a simple for loop), when we got to transfer sizes bigger than the fifo size, dev-buf_len was reset to zero before we had an oportunity to handle XDR Interrupt. Because dev-buf_len was zero, we entered omap_i2c_transmit_data() to transfer zero bytes, which would mean we would just silently exit omap_i2c_transmit_data() without actually writing anything to DATA register. That would cause XDR IRQ to trigger forever and we would never transfer the remaining bytes. After adding the memory barrier, we also drop resetting dev-buf_len to zero in omap_i2c_xfer_msg() because both omap_i2c_transmit_data() and omap_i2c_receive_data() will act until dev-buf_len reaches zero, rendering the other write in omap_i2c_xfer_msg() redundant. This patch has been tested with pandaboard for a few iterations of the script mentioned above. Signed-off-by: Felipe Balbi ba...@ti.com --- This bug has been there forever, but it's quite annoying. I think it deserves being pushed upstream during this -rc cycle, but if Wolfram decides to wait until v3.8, I don't mind. I would add this into 3.7, but what about the comments suggesting to use barrier()? -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
[PATCH 0/3] more omap clean-up for ARCH_MULTIPLATFORM
Hi all, Here are patches to remove some now unnecessary code in preparation for enabling ARCH_MULTIPLATFORM for omap2+. These are based on omap-for-v3.8/cleanup-headers-relative branch. Regards, Tony --- Tony Lindgren (3): ARM: OMAP: Remove unnecessary mach and plat includes ARM: OMAP: Remove NEED_MACH_GPIO_H ARM: OMAP: Remove plat-omap/common.c arch/arm/Kconfig|1 - arch/arm/mach-omap1/gpio15xx.c |2 ++ arch/arm/mach-omap1/gpio16xx.c |2 ++ arch/arm/mach-omap1/gpio7xx.c |2 ++ arch/arm/mach-omap1/include/mach/gpio.h |3 --- arch/arm/mach-omap2/board-2430sdp.c |1 - arch/arm/mach-omap2/board-cm-t35.c |2 -- arch/arm/mach-omap2/hsmmc.c |1 - arch/arm/mach-omap2/include/mach/gpio.h |3 --- arch/arm/plat-omap/Makefile |2 +- arch/arm/plat-omap/common.c | 26 -- arch/arm/plat-omap/debug-devices.c |1 - arch/arm/plat-omap/dma.c|8 arch/arm/plat-omap/dmtimer.c|4 +--- arch/arm/plat-omap/fb.c |1 - arch/arm/plat-omap/i2c.c|2 -- include/linux/platform_data/gpio-omap.h |1 - sound/soc/omap/am3517evm.c |2 -- sound/soc/omap/n810.c |1 - sound/soc/omap/osk5912.c|1 - sound/soc/omap/sdp3430.c|2 -- sound/soc/omap/zoom2.c |3 --- 22 files changed, 16 insertions(+), 55 deletions(-) delete mode 100644 arch/arm/mach-omap1/include/mach/gpio.h delete mode 100644 arch/arm/mach-omap2/include/mach/gpio.h delete mode 100644 arch/arm/plat-omap/common.c -- Signature -- 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
[PATCH 1/3] ARM: OMAP: Remove unnecessary mach and plat includes
Now mach/hardware.h is empty for omap2+ and can be removed except for plat-omap/dmtimer.c for omap1. Also the include of mach/irqs.h can now be removed for shared plat-omap/i2c.c as it's no longer needed. Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/mach-omap2/board-2430sdp.c |1 - arch/arm/mach-omap2/board-cm-t35.c |2 -- arch/arm/mach-omap2/hsmmc.c |1 - arch/arm/plat-omap/debug-devices.c |1 - arch/arm/plat-omap/dmtimer.c|4 +--- arch/arm/plat-omap/fb.c |1 - arch/arm/plat-omap/i2c.c|2 -- 7 files changed, 1 insertion(+), 11 deletions(-) diff --git a/arch/arm/mach-omap2/board-2430sdp.c b/arch/arm/mach-omap2/board-2430sdp.c index 3fc6d83..d1c0162 100644 --- a/arch/arm/mach-omap2/board-2430sdp.c +++ b/arch/arm/mach-omap2/board-2430sdp.c @@ -28,7 +28,6 @@ #include linux/io.h #include linux/gpio.h -#include mach/hardware.h #include asm/mach-types.h #include asm/mach/arch.h #include asm/mach/map.h diff --git a/arch/arm/mach-omap2/board-cm-t35.c b/arch/arm/mach-omap2/board-cm-t35.c index cf9449b..a8cad22 100644 --- a/arch/arm/mach-omap2/board-cm-t35.c +++ b/arch/arm/mach-omap2/board-cm-t35.c @@ -44,8 +44,6 @@ #include video/omap-panel-tfp410.h #include linux/platform_data/spi-omap2-mcspi.h -#include mach/hardware.h - #include common.h #include mux.h #include sdram-micron-mt46h32m32lf-6.h diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c index e3406dc..4a96433 100644 --- a/arch/arm/mach-omap2/hsmmc.c +++ b/arch/arm/mach-omap2/hsmmc.c @@ -14,7 +14,6 @@ #include linux/string.h #include linux/delay.h #include linux/gpio.h -#include mach/hardware.h #include linux/platform_data/gpio-omap.h #include soc.h diff --git a/arch/arm/plat-omap/debug-devices.c b/arch/arm/plat-omap/debug-devices.c index b49be51..a609e21 100644 --- a/arch/arm/plat-omap/debug-devices.c +++ b/arch/arm/plat-omap/debug-devices.c @@ -15,7 +15,6 @@ #include linux/io.h #include linux/smc91x.h -#include mach/hardware.h #include plat/debug-devices.h /* Many OMAP development platforms reuse the same debug board; these diff --git a/arch/arm/plat-omap/dmtimer.c b/arch/arm/plat-omap/dmtimer.c index 9a0bbc4..82231a7 100644 --- a/arch/arm/plat-omap/dmtimer.c +++ b/arch/arm/plat-omap/dmtimer.c @@ -43,8 +43,6 @@ #include plat/dmtimer.h -#include mach/hardware.h - static u32 omap_reserved_systimers; static LIST_HEAD(omap_timer_list); static DEFINE_SPINLOCK(dm_timer_lock); @@ -270,7 +268,7 @@ int omap_dm_timer_get_irq(struct omap_dm_timer *timer) EXPORT_SYMBOL_GPL(omap_dm_timer_get_irq); #if defined(CONFIG_ARCH_OMAP1) - +#include mach/hardware.h /** * omap_dm_timer_modify_idlect_mask - Check if any running timers use ARMXOR * @inputmask: current value of idlect mask diff --git a/arch/arm/plat-omap/fb.c b/arch/arm/plat-omap/fb.c index f868cae..3a77b30 100644 --- a/arch/arm/plat-omap/fb.c +++ b/arch/arm/plat-omap/fb.c @@ -30,7 +30,6 @@ #include linux/io.h #include linux/omapfb.h -#include mach/hardware.h #include asm/mach/map.h #include plat/cpu.h diff --git a/arch/arm/plat-omap/i2c.c b/arch/arm/plat-omap/i2c.c index 4645dd4..f9df624 100644 --- a/arch/arm/plat-omap/i2c.c +++ b/arch/arm/plat-omap/i2c.c @@ -33,8 +33,6 @@ #include plat/i2c.h -#include mach/irqs.h - #define OMAP_I2C_MAX_CONTROLLERS 4 static struct omap_i2c_bus_platform_data i2c_pdata[OMAP_I2C_MAX_CONTROLLERS]; -- 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
[PATCH 3/3] ARM: OMAP: Remove plat-omap/common.c
This file has only omap_init_consistent_dma_size()
left that can be moved to plat-omap/dma.c.
Signed-off-by: Tony Lindgren t...@atomide.com
---
arch/arm/plat-omap/Makefile |2 +-
arch/arm/plat-omap/common.c | 26 --
arch/arm/plat-omap/dma.c|8
3 files changed, 9 insertions(+), 27 deletions(-)
delete mode 100644 arch/arm/plat-omap/common.c
diff --git a/arch/arm/plat-omap/Makefile b/arch/arm/plat-omap/Makefile
index 50da9bf..8d88584 100644
--- a/arch/arm/plat-omap/Makefile
+++ b/arch/arm/plat-omap/Makefile
@@ -3,7 +3,7 @@
#
# Common support
-obj-y := common.o sram.o dma.o fb.o counter_32k.o
+obj-y := sram.o dma.o fb.o counter_32k.o
obj-m :=
obj-n :=
obj- :=
diff --git a/arch/arm/plat-omap/common.c b/arch/arm/plat-omap/common.c
deleted file mode 100644
index bf6cd80..000
--- a/arch/arm/plat-omap/common.c
+++ /dev/null
@@ -1,26 +0,0 @@
-/*
- * linux/arch/arm/plat-omap/common.c
- *
- * Code common to all OMAP machines.
- * The file is created by Tony Lindgren t...@atomide.com
- *
- * Copyright (C) 2009 Texas Instruments
- * Added OMAP4 support - Santosh Shilimkar santosh.shilim...@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.
- */
-#include linux/kernel.h
-#include linux/init.h
-#include linux/io.h
-#include linux/dma-mapping.h
-
-#include plat-omap/dma-omap.h
-
-void __init omap_init_consistent_dma_size(void)
-{
-#ifdef CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE
- init_consistent_dma_size(CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE 20);
-#endif
-}
diff --git a/arch/arm/plat-omap/dma.c b/arch/arm/plat-omap/dma.c
index c288b76..00a3a53 100644
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -2146,6 +2146,14 @@ static struct platform_driver omap_system_dma_driver = {
},
};
+/* This must be called from init_early() */
+void __init omap_init_consistent_dma_size(void)
+{
+#ifdef CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE
+ init_consistent_dma_size(CONFIG_FB_OMAP_CONSISTENT_DMA_SIZE 20);
+#endif
+}
+
static int __init omap_system_dma_init(void)
{
return platform_driver_register(omap_system_dma_driver);
--
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
[PATCH 2/3] ARM: OMAP: Remove NEED_MACH_GPIO_H
Omap no longer needs this option, mach/gpio.h is empty. Also remove mach/irqs.h from gpio-omap.h and include it directly from the related omap1 gpio init files. Otherwise omap2+ build fails for MULTI_PLATFORM. Cc: Peter Ujfalusi peter.ujfal...@ti.com Cc: Jarkko Nikula jarkko.nik...@bitmer.com Cc: Liam Girdwood l...@ti.com Cc: Mark Brown broo...@opensource.wolfsonmicro.com Cc: alsa-de...@alsa-project.org Signed-off-by: Tony Lindgren t...@atomide.com --- arch/arm/Kconfig|1 - arch/arm/mach-omap1/gpio15xx.c |2 ++ arch/arm/mach-omap1/gpio16xx.c |2 ++ arch/arm/mach-omap1/gpio7xx.c |2 ++ arch/arm/mach-omap1/include/mach/gpio.h |3 --- arch/arm/mach-omap2/include/mach/gpio.h |3 --- include/linux/platform_data/gpio-omap.h |1 - sound/soc/omap/am3517evm.c |2 -- sound/soc/omap/n810.c |1 - sound/soc/omap/osk5912.c|1 - sound/soc/omap/sdp3430.c|2 -- sound/soc/omap/zoom2.c |3 --- 12 files changed, 6 insertions(+), 17 deletions(-) delete mode 100644 arch/arm/mach-omap1/include/mach/gpio.h delete mode 100644 arch/arm/mach-omap2/include/mach/gpio.h diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 73067ef..6207cf7 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -937,7 +937,6 @@ config ARCH_OMAP select CLKSRC_MMIO select GENERIC_CLOCKEVENTS select HAVE_CLK - select NEED_MACH_GPIO_H help Support for TI's OMAP platform (OMAP1/2/3/4). diff --git a/arch/arm/mach-omap1/gpio15xx.c b/arch/arm/mach-omap1/gpio15xx.c index 98e6f39..02b3eb2 100644 --- a/arch/arm/mach-omap1/gpio15xx.c +++ b/arch/arm/mach-omap1/gpio15xx.c @@ -19,6 +19,8 @@ #include linux/gpio.h #include linux/platform_data/gpio-omap.h +#include mach/irqs.h + #define OMAP1_MPUIO_VBASE OMAP1_MPUIO_BASE #define OMAP1510_GPIO_BASE 0xFFFCE000 diff --git a/arch/arm/mach-omap1/gpio16xx.c b/arch/arm/mach-omap1/gpio16xx.c index 33f4192..b9952a2 100644 --- a/arch/arm/mach-omap1/gpio16xx.c +++ b/arch/arm/mach-omap1/gpio16xx.c @@ -19,6 +19,8 @@ #include linux/gpio.h #include linux/platform_data/gpio-omap.h +#include mach/irqs.h + #define OMAP1610_GPIO1_BASE0xfffbe400 #define OMAP1610_GPIO2_BASE0xfffbec00 #define OMAP1610_GPIO3_BASE0xfffbb400 diff --git a/arch/arm/mach-omap1/gpio7xx.c b/arch/arm/mach-omap1/gpio7xx.c index 958ce9a..f5819b2 100644 --- a/arch/arm/mach-omap1/gpio7xx.c +++ b/arch/arm/mach-omap1/gpio7xx.c @@ -19,6 +19,8 @@ #include linux/gpio.h #include linux/platform_data/gpio-omap.h +#include mach/irqs.h + #define OMAP7XX_GPIO1_BASE 0xfffbc000 #define OMAP7XX_GPIO2_BASE 0xfffbc800 #define OMAP7XX_GPIO3_BASE 0xfffbd000 diff --git a/arch/arm/mach-omap1/include/mach/gpio.h b/arch/arm/mach-omap1/include/mach/gpio.h deleted file mode 100644 index ebf86c0..000 --- a/arch/arm/mach-omap1/include/mach/gpio.h +++ /dev/null @@ -1,3 +0,0 @@ -/* - * arch/arm/mach-omap1/include/mach/gpio.h - */ diff --git a/arch/arm/mach-omap2/include/mach/gpio.h b/arch/arm/mach-omap2/include/mach/gpio.h deleted file mode 100644 index 5621cc5..000 --- a/arch/arm/mach-omap2/include/mach/gpio.h +++ /dev/null @@ -1,3 +0,0 @@ -/* - * arch/arm/mach-omap2/include/mach/gpio.h - */ diff --git a/include/linux/platform_data/gpio-omap.h b/include/linux/platform_data/gpio-omap.h index e8741c2..5d50b25 100644 --- a/include/linux/platform_data/gpio-omap.h +++ b/include/linux/platform_data/gpio-omap.h @@ -26,7 +26,6 @@ #include linux/io.h #include linux/platform_device.h -#include mach/irqs.h #define OMAP1_MPUIO_BASE 0xfffb5000 diff --git a/sound/soc/omap/am3517evm.c b/sound/soc/omap/am3517evm.c index fad3506..c1900b2 100644 --- a/sound/soc/omap/am3517evm.c +++ b/sound/soc/omap/am3517evm.c @@ -25,8 +25,6 @@ #include sound/soc.h #include asm/mach-types.h -#include mach/hardware.h -#include mach/gpio.h #include linux/platform_data/asoc-ti-mcbsp.h #include omap-mcbsp.h diff --git a/sound/soc/omap/n810.c b/sound/soc/omap/n810.c index 521bfc3..230b8c1 100644 --- a/sound/soc/omap/n810.c +++ b/sound/soc/omap/n810.c @@ -29,7 +29,6 @@ #include sound/soc.h #include asm/mach-types.h -#include mach/hardware.h #include linux/gpio.h #include linux/module.h #include linux/platform_data/asoc-ti-mcbsp.h diff --git a/sound/soc/omap/osk5912.c b/sound/soc/omap/osk5912.c index 3960e8d..06ef8d6 100644 --- a/sound/soc/omap/osk5912.c +++ b/sound/soc/omap/osk5912.c @@ -28,7 +28,6 @@ #include sound/soc.h #include asm/mach-types.h -#include mach/hardware.h #include linux/gpio.h #include linux/module.h #include linux/platform_data/asoc-ti-mcbsp.h diff --git a/sound/soc/omap/sdp3430.c b/sound/soc/omap/sdp3430.c index 597cae7..b462a2c 100644 --- a/sound/soc/omap/sdp3430.c +++ b/sound/soc/omap/sdp3430.c @@
Re: [PATCH] i2c: omap: fix spurious IRQs: disable/enable IRQ at INTC when idle
Hi, Anyway new patch coming soon :) Was there one? I have skimmed a number of threads discussing spurious interrupts or interrupt floods but AFAICS all discussions ended up in trying another approach later or fixing the issue somewhere else than I2C. Is this correct? Or is there a bugfix patch left for 3.7 that I missed? Thanks, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCH 3/3] ARM: OMAP: Remove plat-omap/common.c
* Tony Lindgren t...@atomide.com [121101 15:50]: This file has only omap_init_consistent_dma_size() left that can be moved to plat-omap/dma.c. And this one needs the following compile fix for omap1 at least for Nokia 770. I'll fold it in. Regards, Tony --- a/arch/arm/plat-omap/dma.c +++ b/arch/arm/plat-omap/dma.c @@ -35,6 +35,7 @@ #include linux/io.h #include linux/slab.h #include linux/delay.h +#include linux/dma-mapping.h #include plat-omap/dma-omap.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
Re: [PATCH 0/3] capebus moving omap_devices to mach-omap2
On Thu, Nov 1, 2012 at 3:05 PM, Felipe Balbi ba...@ti.com wrote: HI, On Thu, Nov 01, 2012 at 03:59:50PM +0200, Pantelis Antoniou wrote: Hi Alan, On Nov 1, 2012, at 3:51 PM, Alan Cox wrote: What they want, and what every user wants, is I plug this board in, and the driver make sure everything is loaded and ready. No, the end users don't want to see any of the implementation details of how the bitfile is transported; the driver can handle it. That doesn't necessarily make it a bus merely some kind of hotplug enumeration of devices. That should all work properly both for devices and busses with spi and i²c as the final bits needed for it got fixed some time ago. In an ideal world you don't want to be writing custom drivers for stuff. If your cape routes an i²c serial device to the existing system i²c busses then you want to just create an instance of any existing driver on the existing i²c bus not create a whole new layer of goop. It does need to do the plumbing and resource management for the plumbing but thats not the same as being a bus. Alan 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. 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 flexible. One devices read may be another devices write. A detect method that only performs reads could easily toggle a gpio that resets the board, rewrite and eeprom, or set the printer on fire. If you browse through various detect functions, yes, some of them key off an ID, but a lot of them just check various registers to see if certain bits are zero, or certain bits are one. A lot of I²C devices I've dealt with have no good way of probing them, especially GPIO chips (you'll notice none of the I²C GPIO expanders have detect functions) On top of all this the detect routine does not tell you if the alert pin is connected to some IRQ, or in the case of a GPIO expander, what those GPIOs are connected to, etc, etc. -- 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 V3] mmc: omap_hsmmc: Enable HSPE bit for high speed cards
On Thu, Nov 01, 2012 at 01:46:26, Balbi, Felipe wrote: Hi, On Thu, Nov 01, 2012 at 01:21:36AM +0530, Venkatraman S wrote: On Wed, Oct 31, 2012 at 5:56 PM, Felipe Balbi ba...@ti.com wrote: Hi, On Wed, Oct 31, 2012 at 05:27:36PM +0530, Hebbar, Gururaja wrote: HSMMC IP on AM33xx need a special setting to handle High-speed cards. Other platforms like TI81xx, OMAP4 may need this as-well. This depends on the HSMMC IP timing closure done for the high speed cards. From AM335x TRM (SPRUH73F - 18.3.12 Output Signals Generation) The MMC/SD/SDIO output signals can be driven on either falling edge or rising edge depending on the SD_HCTL[2] HSPE bit. This feature allows to reach better timing performance, and thus to increase data transfer frequency. There are few pre-requisites for enabling the HSPE bit - Controller should support High-Speed-Enable Bit and - Controller should not be using DDR Mode and - Controller should advertise that it supports High Speed in capabilities register and - MMC/SD clock coming out of controller 25MHz Note: The implementation reuses the output of calc_divisor() so as to reduce code addition. Signed-off-by: Hebbar, Gururaja gururaja.heb...@ti.com this looks good to my eyes, hopefully I haven't missed anything: Reviewed-by: Felipe Balbi ba...@ti.com Except for the excessively verbose comments which are just duplicating the code, Quote + * Enable High-Speed Support + * Pre-Requisites + * - Controller should support High-Speed-Enable Bit + * - Controller should not be using DDR Mode + * - Controller should advertise that it supports High Speed + *in capabilities register + * - MMC/SD clock coming out of controller 25MHz + */ /Quote I'm ok with this patch as well. I'm putting a few patches under test including this one, and will send it to Chris as part of that series. I'll strip out the above mentioned comments, unless there are any objections. please don't. Detailing the pre-requisites for getting HSP mode working isn't bad at all. Should someone decide to change the behavior and ends up breaking it, the comment will help putting things back together. my 2 cents, you've got the final decision though. Same here. Description is required in commit message since it will help in during git bisect. -- balbi Regards, Gururaja -- 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
