Re: [PATCH 1/5] capemgr: Beaglebone DT overlay based cape manager
Hi Arnd, On Jan 7, 2013, at 11:35 PM, Arnd Bergmann wrote: (Adding Sascha Hauer, Linus Walleij, Lee Jones to Cc) On Monday 07 January 2013, Tony Lindgren wrote: At the end of the line, some kind of hardware glue is going to be needed. I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw in the beagleboard), it is a bit premature to think about making it overly general, besides the part that are obviously part of the infrastructure (like the DT overlay stuff). What I'm getting at, is that we need some user experience about this, before going away and creating structure out of possible misconception about the uses. IMHO stuff like this will be needed by many SoCs. Some examples of similar things for omaps that have eventually become generic frameworks have been the clock framework, USB OTG support, runtime PM, pinmux framework and so on. So I suggest a minimal generic API from the start as that will make things a lot easier in the long run. I agree. The ux500 platform already has the concept of user interface boards, which currently is not well integrated into devicetree. I believe Sascha mentioned that Pengutronix had been shipping some other systems with add-on boards and generating device tree binaries from source for each combination. Ideally, both of the above should be able to use the same DT overlay logic as BeagleBone, and I'm sure there are more of those. Arnd Hmm, I see. I will need some more information about the interface of the 'user interface boards'. I.e. how is the board identified, what is typically present on those boards, etc. Can we get some input by the owner of other similar hardware? I know the FPGA people have similar requirements for example. There are other people that are hitting problems getting DT to work with their systems, like the V4L people with the order of initialization; see http://lwn.net/Articles/531068/. I think the V4L problem is cleanly solved by the overlay being contained in the V4L device node and applied just before the device is probed. In the meantime it would be better to wait until we have some ack from the maintainers of the core subsystems about what they think. 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: Build failure with DMA_OMAP=m and a caller built-in
On Mon, Jan 07, 2013 at 08:38:34PM +, Russell King - ARM Linux wrote: On Mon, Jan 07, 2013 at 12:21:06PM -0800, Tony Lindgren wrote: * Ben Hutchings b...@decadent.org.uk [130105 21:29]: Various drivers use omap_dma_filter_fn() but don't depend on DMA_OMAP. This is fine because there is a trivial inline definition in case DMA_OMAP is disabled... until the caller is built-in and DMA_OMAP=m. I tried adding the rather weird 'select DMA_OMAP if DMA_OMAP!=n' to these drivers' kconfig symbols to promote it to built-in if necessary. This sort of works but kconfig complains about the circular dependency and it becomes impossible to disable DMA_OMAP in the 'make nconfig' menu. So that's not the right thing to do. Any ideas? Hmm let's ask Russell and Vinod what they are envisioning. I believe there was some talk about removing the filter functions? The right thing is to nobble down and try and resolve the age old, much talked about, common way to tie peripheral devices and their DMA engine channels together by some means. Unfortunately, it seems everyone has different views, and as yet it's not reached any kind of concensus. This has now been going on for a couple of years in various forms. The problem we have is that the way peripheral devices are connected to their DMA engines can involve additional complexity, which if not handled correctly results in some platforms being crippled by the API. I think Vinod was working on something, however I've not heard anything on that for a while now. My work was stalled due to other stuff at my workplace. I plan to spend some time on this pretty soon. How we avoid this problem outside of OMAP is that the DMA filter function gets passed from platform code, and we only ever allow the DMA engine driver to be configured into the kernel (iow, non-modular). This means that the DMA users never directly reference the DMA engine driver itself. However, as OMAP headed down the DT path, many drivers no longer make use of platform data, which makes that approach impractical. So, I'm afraid that OMAP's rather boxed into a corner over the various different competing factions about how ARM should do X, Y and Z vs the state of various subsystems. So much for DT sorting out world hunger and it never failing to solve any problem... I'm sure it'll eventually get sorted, but how long that takes depends on how long it takes to come up with a working API for connecting peripheral devices with their DMA agent(s). -- 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 RESEND] ARM: dts: AM33XX: Rename I2C and GPIO nodes
AnilKumar == AnilKumar, Chimata anilku...@ti.com writes: AnilKumar On Wed, Nov 21, 2012 at 17:22:17, AnilKumar, Chimata wrote: Rename I2C and GPIO nodes according to AM33XX TRM. According to AM33XX TRM device instances are starting from 0 like i2c0, i2c1 and i2c3. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com [pa...@antoniou-consulting.com: initial patch by pantelis's] Signed-off-by: AnilKumar Ch anilku...@ti.com --- Changes from first version: - Updated pantelis's patch * Modified based on linux-omap/master * Added GPIO nodes renaming as well AnilKumar Hi Tony/Benoit, AnilKumar If there are no comments could you please pull this patch? Yes, please do. -- Bye, Peter Korsgaard -- 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 1/5] capemgr: Beaglebone DT overlay based cape manager
(adding linux-media ML to cc) Hi Pantelis On Tue, 8 Jan 2013, Pantelis Antoniou wrote: Hi Arnd, On Jan 7, 2013, at 11:35 PM, Arnd Bergmann wrote: (Adding Sascha Hauer, Linus Walleij, Lee Jones to Cc) On Monday 07 January 2013, Tony Lindgren wrote: At the end of the line, some kind of hardware glue is going to be needed. I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw in the beagleboard), it is a bit premature to think about making it overly general, besides the part that are obviously part of the infrastructure (like the DT overlay stuff). What I'm getting at, is that we need some user experience about this, before going away and creating structure out of possible misconception about the uses. IMHO stuff like this will be needed by many SoCs. Some examples of similar things for omaps that have eventually become generic frameworks have been the clock framework, USB OTG support, runtime PM, pinmux framework and so on. So I suggest a minimal generic API from the start as that will make things a lot easier in the long run. I agree. The ux500 platform already has the concept of user interface boards, which currently is not well integrated into devicetree. I believe Sascha mentioned that Pengutronix had been shipping some other systems with add-on boards and generating device tree binaries from source for each combination. Ideally, both of the above should be able to use the same DT overlay logic as BeagleBone, and I'm sure there are more of those. Arnd Hmm, I see. I will need some more information about the interface of the 'user interface boards'. I.e. how is the board identified, what is typically present on those boards, etc. Can we get some input by the owner of other similar hardware? I know the FPGA people have similar requirements for example. There are other people that are hitting problems getting DT to work with their systems, like the V4L people with the order of initialization; see http://lwn.net/Articles/531068/. I think the V4L problem is cleanly solved by the overlay being contained in the V4L device node and applied just before the device is probed. You probably mean these related V4L patches: http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/58646 that base upon of asynchronous V4L2 subdevice probing, referenced above. Yes, V4L DT nodes, as documented in http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/58646/focus=58648 contain port and endpoint nodes, that describe the configuration of the hardware port and link to devices, connected to it. Not sure how well this would work with DT overlays, because endpoint nodes on both sides of the video data bus contain references to the other side and I don't know whether and how these can be created and / or updated at run-time. Otherwise, yes, the approach that we're currently developing on V4L allows us to build video data pipelines independent of (sub)device driver probing order. Thanks Guennadi In the meantime it would be better to wait until we have some ack from the maintainers of the core subsystems about what they think. Regards -- Pantelis --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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 1/5] capemgr: Beaglebone DT overlay based cape manager
At the end of the line, some kind of hardware glue is going to be needed. I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw in the beagleboard), it is a bit premature to think about making it overly general, besides the part that are obviously part of the infrastructure (like the DT overlay stuff). What I'm getting at, is that we need some user experience about this, before going away and creating structure out of possible misconception about the uses. IMHO stuff like this will be needed by many SoCs. Some examples of similar things for omaps that have eventually become generic frameworks have been the clock framework, USB OTG support, runtime PM, pinmux framework and so on. So I suggest a minimal generic API from the start as that will make things a lot easier in the long run. I agree. The ux500 platform already has the concept of user interface boards, which currently is not well integrated into devicetree. I believe Sascha mentioned that Pengutronix had been shipping some other systems with add-on boards and generating device tree binaries from source for each combination. Ideally, both of the above should be able to use the same DT overlay logic as BeagleBone, and I'm sure there are more of those. Hmm, I see. I will need some more information about the interface of the 'user interface boards'. I.e. how is the board identified, what is typically present on those boards, etc. User Interface Boards are mearly removable PCBs which are interchangeable amongst various hardware platforms. They are connected via numerous connectors which carry all sorts of different data links; i2c, spi, rs232, etc. The UIB I'm looking at right now has a touchscreen, speakers, a key pad, leds, jumpers, switches and a bunch of sensors. You can find a small example of how we interface to these by viewing 'arch/arm/boot/dts/stuib.dtsi'. To add a UIB to a particular build, we currently include it as a *.dtsi from a platform's dts file. Can we get some input by the owner of other similar hardware? I know the FPGA people have similar requirements for example. There are other people that are hitting problems getting DT to work with their systems, like the V4L people with the order of initialization; see http://lwn.net/Articles/531068/. I think the V4L problem is cleanly solved by the overlay being contained in the V4L device node and applied just before the device is probed. In the meantime it would be better to wait until we have some ack from the maintainers of the core subsystems about what they think. Regards -- Pantelis -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 1/5] capemgr: Beaglebone DT overlay based cape manager
Hi Guennadi,
On Jan 8, 2013, at 11:51 AM, Guennadi Liakhovetski wrote:
(adding linux-media ML to cc)
Hi Pantelis
On Tue, 8 Jan 2013, Pantelis Antoniou wrote:
Hi Arnd,
On Jan 7, 2013, at 11:35 PM, Arnd Bergmann wrote:
(Adding Sascha Hauer, Linus Walleij, Lee Jones to Cc)
On Monday 07 January 2013, Tony Lindgren wrote:
At the end of the line, some kind of hardware glue is going to be needed.
I just feel that drawing from a sample size of 1 (maybe 2 if I get to
throw
in the beagleboard), it is a bit premature to think about making it overly
general, besides the part that are obviously part of the infrastructure
(like the DT overlay stuff).
What I'm getting at, is that we need some user experience about this,
before
going away and creating structure out of possible misconception about the
uses.
IMHO stuff like this will be needed by many SoCs. Some examples of similar
things for omaps that have eventually become generic frameworks have been
the clock framework, USB OTG support, runtime PM, pinmux framework and
so on.
So I suggest a minimal generic API from the start as that will make things
a lot easier in the long run.
I agree. The ux500 platform already has the concept of user interface
boards,
which currently is not well integrated into devicetree. I believe Sascha
mentioned that Pengutronix had been shipping some other systems with add-on
boards and generating device tree binaries from source for each combination.
Ideally, both of the above should be able to use the same DT overlay logic
as BeagleBone, and I'm sure there are more of those.
Arnd
Hmm, I see.
I will need some more information about the interface of the 'user interface
boards'.
I.e. how is the board identified, what is typically present on those boards,
etc.
Can we get some input by the owner of other similar hardware? I know the FPGA
people have similar requirements for example. There are other people that
are hitting
problems getting DT to work with their systems, like the V4L people with the
order
of initialization; see http://lwn.net/Articles/531068/. I think the V4L
problem is
cleanly solved by the overlay being contained in the V4L device node and
applied just before
the device is probed.
You probably mean these related V4L patches:
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/58646
that base upon of asynchronous V4L2 subdevice probing, referenced above.
Yes, V4L DT nodes, as documented in
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/58646/focus=58648
contain port and endpoint nodes, that describe the configuration of
the hardware port and link to devices, connected to it. Not sure how well
this would work with DT overlays, because endpoint nodes on both sides of
the video data bus contain references to the other side and I don't know
whether and how these can be created and / or updated at run-time.
Otherwise, yes, the approach that we're currently developing on V4L allows
us to build video data pipelines independent of (sub)device driver probing
order.
I'm not very well versed at the V4L intricacies, and correct me if I got it
wrong,
but it seems like you have the problem on needing to probe a bunch of devices
only after
the parent device has been probed successfully.
Your async subdevice probing method seems to be doing this.
It might be simpler to do something like this:
v4ldevice {
compatible = foo,v4ldev;
...
overlay {
fragment@0 {
target = i2c0;
__overlay__ {
...
/* i2c devices */
};
};
fragment@0 {
target = ocp;
__overlay__ {
..
/* platform devices */
};
};
...
}:
};
And in the probe of the v4ldev apply the overlay. The i2c devices will end up
in the
i2c node, the platform devices to the ocp node, etc, and will be registered.
There is nothing preventing the overlay being in a part of the board dts file.
You will need to do a resolve pass for the phandles, but it's not
insurmountable IMO.
Regards
-- Pantelis
Thanks
Guennadi
In the meantime it would be better to wait until we have some ack from the
maintainers
of the core subsystems about what they think.
Regards
-- Pantelis
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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 1/5] capemgr: Beaglebone DT overlay based cape manager
Hi Lee, On Jan 8, 2013, at 12:00 PM, Lee Jones wrote: At the end of the line, some kind of hardware glue is going to be needed. I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw in the beagleboard), it is a bit premature to think about making it overly general, besides the part that are obviously part of the infrastructure (like the DT overlay stuff). What I'm getting at, is that we need some user experience about this, before going away and creating structure out of possible misconception about the uses. IMHO stuff like this will be needed by many SoCs. Some examples of similar things for omaps that have eventually become generic frameworks have been the clock framework, USB OTG support, runtime PM, pinmux framework and so on. So I suggest a minimal generic API from the start as that will make things a lot easier in the long run. I agree. The ux500 platform already has the concept of user interface boards, which currently is not well integrated into devicetree. I believe Sascha mentioned that Pengutronix had been shipping some other systems with add-on boards and generating device tree binaries from source for each combination. Ideally, both of the above should be able to use the same DT overlay logic as BeagleBone, and I'm sure there are more of those. Hmm, I see. I will need some more information about the interface of the 'user interface boards'. I.e. how is the board identified, what is typically present on those boards, etc. User Interface Boards are mearly removable PCBs which are interchangeable amongst various hardware platforms. They are connected via numerous connectors which carry all sorts of different data links; i2c, spi, rs232, etc. The UIB I'm looking at right now has a touchscreen, speakers, a key pad, leds, jumpers, switches and a bunch of sensors. You can find a small example of how we interface to these by viewing 'arch/arm/boot/dts/stuib.dtsi'. To add a UIB to a particular build, we currently include it as a *.dtsi from a platform's dts file. I see. What I'm asking about is whether there's a method where you can read an EEPROM, or some GPIO code combination where I can find out what kind of board is plugged each time. If there is not, there is no way to automatically load the overlays; you can always use the kernel command line, or have the a user space application to request the loading of a specific board's overlay. Regards -- Pantelis Can we get some input by the owner of other similar hardware? I know the FPGA people have similar requirements for example. There are other people that are hitting problems getting DT to work with their systems, like the V4L people with the order of initialization; see http://lwn.net/Articles/531068/. I think the V4L problem is cleanly solved by the overlay being contained in the V4L device node and applied just before the device is probed. In the meantime it would be better to wait until we have some ack from the maintainers of the core subsystems about what they think. Regards -- Pantelis -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 1/5] capemgr: Beaglebone DT overlay based cape manager
On Tue, 08 Jan 2013, Pantelis Antoniou wrote: Hi Lee, On Jan 8, 2013, at 12:00 PM, Lee Jones wrote: At the end of the line, some kind of hardware glue is going to be needed. I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw in the beagleboard), it is a bit premature to think about making it overly general, besides the part that are obviously part of the infrastructure (like the DT overlay stuff). What I'm getting at, is that we need some user experience about this, before going away and creating structure out of possible misconception about the uses. IMHO stuff like this will be needed by many SoCs. Some examples of similar things for omaps that have eventually become generic frameworks have been the clock framework, USB OTG support, runtime PM, pinmux framework and so on. So I suggest a minimal generic API from the start as that will make things a lot easier in the long run. I agree. The ux500 platform already has the concept of user interface boards, which currently is not well integrated into devicetree. I believe Sascha mentioned that Pengutronix had been shipping some other systems with add-on boards and generating device tree binaries from source for each combination. Ideally, both of the above should be able to use the same DT overlay logic as BeagleBone, and I'm sure there are more of those. Hmm, I see. I will need some more information about the interface of the 'user interface boards'. I.e. how is the board identified, what is typically present on those boards, etc. User Interface Boards are mearly removable PCBs which are interchangeable amongst various hardware platforms. They are connected via numerous connectors which carry all sorts of different data links; i2c, spi, rs232, etc. The UIB I'm looking at right now has a touchscreen, speakers, a key pad, leds, jumpers, switches and a bunch of sensors. You can find a small example of how we interface to these by viewing 'arch/arm/boot/dts/stuib.dtsi'. To add a UIB to a particular build, we currently include it as a *.dtsi from a platform's dts file. I see. What I'm asking about is whether there's a method where you can read an EEPROM, or some GPIO code combination where I can find out what kind of board is plugged each time. If there is not, there is no way to automatically load the overlays; you can always use the kernel command line, or have the a user space application to request the loading of a specific board's overlay. Unfortunately, there is no way to probe the UIBs. :( Can we get some input by the owner of other similar hardware? I know the FPGA people have similar requirements for example. There are other people that are hitting problems getting DT to work with their systems, like the V4L people with the order of initialization; see http://lwn.net/Articles/531068/. I think the V4L problem is cleanly solved by the overlay being contained in the V4L device node and applied just before the device is probed. In the meantime it would be better to wait until we have some ack from the maintainers of the core subsystems about what they think. -- Lee Jones Linaro ST-Ericsson Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- 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 1/5] capemgr: Beaglebone DT overlay based cape manager
On Mon, Jan 07, 2013 at 09:35:04PM +, Arnd Bergmann wrote: (Adding Sascha Hauer, Linus Walleij, Lee Jones to Cc) On Monday 07 January 2013, Tony Lindgren wrote: At the end of the line, some kind of hardware glue is going to be needed. I just feel that drawing from a sample size of 1 (maybe 2 if I get to throw in the beagleboard), it is a bit premature to think about making it overly general, besides the part that are obviously part of the infrastructure (like the DT overlay stuff). What I'm getting at, is that we need some user experience about this, before going away and creating structure out of possible misconception about the uses. IMHO stuff like this will be needed by many SoCs. Some examples of similar things for omaps that have eventually become generic frameworks have been the clock framework, USB OTG support, runtime PM, pinmux framework and so on. So I suggest a minimal generic API from the start as that will make things a lot easier in the long run. I agree. The ux500 platform already has the concept of user interface boards, which currently is not well integrated into devicetree. I believe Sascha mentioned that Pengutronix had been shipping some other systems with add-on boards and generating device tree binaries from source for each combination. What we have is usually CPU modules which can have different base boards. Usually they are not detectable by software. Right now we normally use a baseboard dts which includes a board dtd which then includes the SoC dtsi. This works quite well on dtc level. For us overlay dts become interesting when it comes to all the little variants of the boards, like for example different displays, different touchscreens,... Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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 1/5] capemgr: Beaglebone DT overlay based cape manager
On Tuesday 08 January 2013, Lee Jones wrote: If there is not, there is no way to automatically load the overlays; you can always use the kernel command line, or have the a user space application to request the loading of a specific board's overlay. Unfortunately, there is no way to probe the UIBs. :( I thought that some of the newer UIBs had it, just not the old ones. As Pantelis says, we could at least detect the ones that have an EEPROM on them, and use a command line option or device tree attribute for the others. Arnd -- 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 1/5] capemgr: Beaglebone DT overlay based cape manager
Hi Arnd, On Jan 8, 2013, at 2:12 PM, Arnd Bergmann wrote: On Tuesday 08 January 2013, Lee Jones wrote: If there is not, there is no way to automatically load the overlays; you can always use the kernel command line, or have the a user space application to request the loading of a specific board's overlay. Unfortunately, there is no way to probe the UIBs. :( I thought that some of the newer UIBs had it, just not the old ones. As Pantelis says, we could at least detect the ones that have an EEPROM on them, and use a command line option or device tree attribute for the others. Arnd So I gather the new ones have an eeprom? 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
[PATCH] omap: DT node Timer iteration fix
The iterator correctly handles of_node_put() calls.
Remove it before continue'ing the loop.
Without this patch you get:
ERROR: Bad of_node_put() on /ocp/timer@44e31000!
[c001329c] (unwind_backtrace+0x0/0xe0) from [c03dd8f0]
(of_node_release+0x2c/0xa0)!
[c03dd8f0] (of_node_release+0x2c/0xa0) from [c03ddea0]
(of_find_matching_node_and_match+0x78/0x90)!
[c03ddea0] (of_find_matching_node_and_match+0x78/0x90) from [c06d349c]
(omap_get_timer_dt+0x78/0x90)!
[c06d349c] (omap_get_timer_dt+0x78/0x90) from [c06d3664]
(omap_dm_timer_init_one.clone.2+0x34/0x2bc)!
[c06d3664] (omap_dm_timer_init_one.clone.2+0x34/0x2bc) from [c06d3a2c]
(omap2_gptimer_clocksource_init.clone.4+0x24/0xa8)!
[c06d3a2c] (omap2_gptimer_clocksource_init.clone.4+0x24/0xa8) from
[c06cca58] (time_init+0x20/0x30)!
[c06cca58] (time_init+0x20/0x30) from [c06c9690] (start_kernel+0x1a8/0x2fc)!
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
arch/arm/mach-omap2/timer.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 691aa67..b8ad6e6 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -165,15 +165,11 @@ static struct device_node * __init
omap_get_timer_dt(struct of_device_id *match,
struct device_node *np;
for_each_matching_node(np, match) {
- if (!of_device_is_available(np)) {
- of_node_put(np);
+ if (!of_device_is_available(np))
continue;
- }
- if (property !of_get_property(np, property, NULL)) {
- of_node_put(np);
+ if (property !of_get_property(np, property, NULL))
continue;
- }
of_add_property(np, device_disabled);
return np;
--
1.7.12
--
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] omap: Avoid crashes in the case of hwmod misconfiguration
omap hwmod is really sensitive to hwmod misconfiguration.
Getting a minor clock wrong always ended up in a crash.
Attempt to be more resilient by not assigning variables with
error codes and then attempting to use them.
Without this patch, missing a clock ends up with something like this:
omap_hwmod: ehrpwm0: cannot clk_get opt_clk ehrpwm0_tbclk!
Unable to handle kernel NULL pointer dereference at virtual address 002a!
pgd = c0004000!
[002a] *pgd=!
Internal error: Oops: 5 [#1] SMP ARM!
Modules linked in:!
CPU: 0Not tainted (3.8.0-rc2-12157-g76c7825-dirty #291)!
PC is at __clk_prepare+0x10/0x70!
LR is at clk_prepare+0x1c/0x34!
pc : [c03e37f0]lr : [c03e386c]psr: a113!
sp : cf04fef8 ip : fp : !
r10: ffea r9 : r8 : !
r7 : fffe r6 : 0001 r5 : fffe r4 : fffe!
r3 : cf041ac0 r2 : cf04ff00 r1 : r0 : fffe!
Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel!
Control: 10c5387d Table: 80004019 DAC: 0015!
Process swapper/0 (pid: 1, stack limit = 0xcf04e240)!
Stack: (0xcf04fef8 to 0xcf05)!
fee0: cf041ac0 c07749f4!
ff00: fffe c03e386c c07499cc c073c070 c073d2fc c06d4e4c c073c070 c071cc18!
ff20: c06d4c4c c0708284 c06c91bc c0025e28 c073a030 0001!
ff40: c06f5f60 c06f5f40 c06d5324 c06d533c cf04e000 c0008870 c06d5324 c060abe8!
ff60: c07082e8 0002 0001 c06f5f60 c06f5f40 c077d700 0099 c04a43d4!
ff80: 0001 0001 c06c91bc c04a42dc !
ffa0: c000d678 !
ffc0: !
ffe0: 0013 9e7befee f7bbaaab!
[c03e37f0] (__clk_prepare+0x10/0x70) from [c03e386c]
(clk_prepare+0x1c/0x34)!
[c03e386c] (clk_prepare+0x1c/0x34) from [c06d4e4c] (_init+0x200/0x288)!
[c06d4e4c] (_init+0x200/0x288) from [c0025e28]
(omap_hwmod_for_each+0x28/0x58)!
[c0025e28] (omap_hwmod_for_each+0x28/0x58) from [c06d533c]
(omap_hwmod_setup_all+0x18/0x34)!
[c06d533c] (omap_hwmod_setup_all+0x18/0x34) from [c0008870]
(do_one_initcall+0x90/0x160)!
[c0008870] (do_one_initcall+0x90/0x160) from [c04a43d4]
(kernel_init+0xf8/0x290)!
[c04a43d4] (kernel_init+0xf8/0x290) from [c000d678]
(ret_from_fork+0x14/0x3c)!
Code: e92d4038 e2504000 01a05004 0a15 (e594302c) !
---[ end trace 1b75b31a2719ed1c ]---!
Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b!
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
---
arch/arm/mach-omap2/omap_hwmod.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index 4653efb..2b58e21 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -783,7 +783,9 @@ static int _init_interface_clks(struct omap_hwmod *oh)
if (IS_ERR(c)) {
pr_warning(omap_hwmod: %s: cannot clk_get
interface_clk %s\n,
oh-name, os-clk);
- ret = -EINVAL;
+ if (ret == 0)
+ ret = -EINVAL;
+ continue;
}
os-_clk = c;
/*
@@ -819,7 +821,9 @@ static int _init_opt_clks(struct omap_hwmod *oh)
if (IS_ERR(c)) {
pr_warning(omap_hwmod: %s: cannot clk_get opt_clk
%s\n,
oh-name, oc-clk);
- ret = -EINVAL;
+ if (ret == 0)
+ ret = -EINVAL;
+ continue;
}
oc-_clk = c;
/*
--
1.7.12
--
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/2] ARM: OMAP3: clock: Back-propagate rate change from cam_mclk to dpll4_m5
The cam_mclk clock is generated through the following clocks chain:
dpll4 - dpll4_m5 - dpll4_m5x2 - cam_mclk
As dpll4_m5 and dpll4_m5x2 do not driver any clock other than cam_mclk,
back-propagate the cam_clk rate changes up to dpll4_m5.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
arch/arm/mach-omap2/cclock3xxx_data.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c
b/arch/arm/mach-omap2/cclock3xxx_data.c
index bdf3948..326b6ad 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -426,6 +426,7 @@ static struct clk dpll4_m5x2_ck_3630 = {
.parent_names = dpll4_m5x2_ck_parent_names,
.num_parents= ARRAY_SIZE(dpll4_m5x2_ck_parent_names),
.ops= dpll4_m5x2_ck_3630_ops,
+ .flags = CLK_SET_RATE_PARENT,
};
static struct clk cam_mclk;
@@ -443,7 +444,14 @@ static struct clk_hw_omap cam_mclk_hw = {
.clkdm_name = cam_clkdm,
};
-DEFINE_STRUCT_CLK(cam_mclk, cam_mclk_parent_names, aes2_ick_ops);
+static struct clk cam_mclk = {
+ .name = cam_mclk,
+ .hw = cam_mclk_hw.hw,
+ .parent_names = cam_mclk_parent_names,
+ .num_parents= ARRAY_SIZE(cam_mclk_parent_names),
+ .ops= aes2_ick_ops,
+ .flags = CLK_SET_RATE_PARENT,
+};
static const struct clksel_rate clkout2_src_core_rates[] = {
{ .div = 1, .val = 0, .flags = RATE_IN_3XXX },
--
1.7.8.6
--
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/2] OMAP3 ISP: Simplify clock usage
Hello, Now that the OMAP3 supports the common clock framework, clock rate back-propagation is available for the ISP clocks. Instead of setting the cam_mclk parent clock rate to control the cam_mclk clock rate, we can mark the dpll4_m5x2_ck_3630 and cam_mclk clocks as supporting back-propagation, and set the cam_mclk rate directly. This simplifies the ISP clocks configuration. Laurent Pinchart (2): ARM: OMAP3: clock: Back-propagate rate change from cam_mclk to dpll4_m5 omap3isp: Set cam_mclk rate directly arch/arm/mach-omap2/cclock3xxx_data.c | 10 +- drivers/media/platform/omap3isp/isp.c | 18 ++ drivers/media/platform/omap3isp/isp.h |8 +++- 3 files changed, 14 insertions(+), 22 deletions(-) -- Regards, Laurent Pinchart -- 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/2] omap3isp: Set cam_mclk rate directly
Now that the cam_mclk rate changes are back-propagated to dpll4_m5_ck we
can set the cam_mclk rate directly instead of manually setting the rate
of the parent clock.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/platform/omap3isp/isp.c | 18 ++
drivers/media/platform/omap3isp/isp.h |8 +++-
2 files changed, 5 insertions(+), 21 deletions(-)
diff --git a/drivers/media/platform/omap3isp/isp.c
b/drivers/media/platform/omap3isp/isp.c
index 07eea5b..63a583f 100644
--- a/drivers/media/platform/omap3isp/isp.c
+++ b/drivers/media/platform/omap3isp/isp.c
@@ -1338,28 +1338,15 @@ static int isp_enable_clocks(struct isp_device *isp)
{
int r;
unsigned long rate;
- int divisor;
-
- /*
-* cam_mclk clock chain:
-* dpll4 - dpll4_m5 - dpll4_m5x2 - cam_mclk
-*
-* In OMAP3630 dpll4_m5x2 != 2 x dpll4_m5 but both are
-* set to the same value. Hence the rate set for dpll4_m5
-* has to be twice of what is set on OMAP3430 to get
-* the required value for cam_mclk
-*/
- divisor = isp-revision == ISP_REVISION_15_0 ? 1 : 2;
r = clk_prepare_enable(isp-clock[ISP_CLK_CAM_ICK]);
if (r) {
dev_err(isp-dev, failed to enable cam_ick clock\n);
goto out_clk_enable_ick;
}
- r = clk_set_rate(isp-clock[ISP_CLK_DPLL4_M5_CK],
-CM_CAM_MCLK_HZ/divisor);
+ r = clk_set_rate(isp-clock[ISP_CLK_CAM_MCLK], CM_CAM_MCLK_HZ);
if (r) {
- dev_err(isp-dev, clk_set_rate for dpll4_m5_ck failed\n);
+ dev_err(isp-dev, clk_set_rate for cam_mclk failed\n);
goto out_clk_enable_mclk;
}
r = clk_prepare_enable(isp-clock[ISP_CLK_CAM_MCLK]);
@@ -1401,7 +1388,6 @@ static void isp_disable_clocks(struct isp_device *isp)
static const char *isp_clocks[] = {
cam_ick,
cam_mclk,
- dpll4_m5_ck,
csi2_96m_fck,
l3_ick,
};
diff --git a/drivers/media/platform/omap3isp/isp.h
b/drivers/media/platform/omap3isp/isp.h
index 517d348..c77e1f2 100644
--- a/drivers/media/platform/omap3isp/isp.h
+++ b/drivers/media/platform/omap3isp/isp.h
@@ -147,7 +147,6 @@ struct isp_platform_callback {
* @ref_count: Reference count for handling multiple ISP requests.
* @cam_ick: Pointer to camera interface clock structure.
* @cam_mclk: Pointer to camera functional clock structure.
- * @dpll4_m5_ck: Pointer to DPLL4 M5 clock structure.
* @csi2_fck: Pointer to camera CSI2 complexIO clock structure.
* @l3_ick: Pointer to OMAP3 L3 bus interface clock.
* @irq: Currently attached ISP ISR callbacks information structure.
@@ -189,10 +188,9 @@ struct isp_device {
u32 xclk_divisor[2];/* Two clocks, a and b. */
#define ISP_CLK_CAM_ICK0
#define ISP_CLK_CAM_MCLK 1
-#define ISP_CLK_DPLL4_M5_CK2
-#define ISP_CLK_CSI2_FCK 3
-#define ISP_CLK_L3_ICK 4
- struct clk *clock[5];
+#define ISP_CLK_CSI2_FCK 2
+#define ISP_CLK_L3_ICK 3
+ struct clk *clock[4];
/* ISP modules */
struct ispstat isp_af;
--
1.7.8.6
--
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 v2 01/18] mailbox: OMAP2+: Add support for AM33XX
On Monday 31 December 2012 06:36 PM, Vaibhav Bedia wrote:
Mailbox IP on AM33XX is the same as that present in OMAP4.
The single instance of Mailbox IP on AM33XX contains
8 sub-modules and facilitates communication between MPU,
PRUs and WKUP_M3.
PRUS?
The first mailbox sub-module is assigned for communication
between MPU and WKUP-M3.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
Cc: Russ Dill russ.d...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
v1-v2:
Address the comment on operator usage from Russ Dill
drivers/mailbox/mailbox-omap2.c | 35 ++-
1 files changed, 34 insertions(+), 1 deletions(-)
diff --git a/drivers/mailbox/mailbox-omap2.c b/drivers/mailbox/mailbox-omap2.c
index 7c26bed..6d61159 100644
--- a/drivers/mailbox/mailbox-omap2.c
+++ b/drivers/mailbox/mailbox-omap2.c
@@ -151,7 +151,7 @@ static void omap2_mbox_disable_irq(struct mailbox *mbox,
struct omap_mbox2_priv *p = mbox-priv;
u32 bit = (irq == IRQ_TX) ? p-notfull_bit : p-newmsg_bit;
- if (!cpu_is_omap44xx())
+ if (!cpu_is_omap44xx() !soc_is_am33xx())
bit = mbox_read_reg(p-irqdisable) ~bit;
mbox_write_reg(bit, p-irqdisable);
@@ -352,6 +352,32 @@ struct mailbox mbox_2_info = {
struct mailbox *omap4_mboxes[] = { mbox_1_info, mbox_2_info, NULL };
#endif
+#if defined(CONFIG_SOC_AM33XX)
+static struct omap_mbox2_priv omap2_mbox_wkup_m3_priv = {
+ .tx_fifo = {
+ .msg= MAILBOX_MESSAGE(0),
+ .fifo_stat = MAILBOX_FIFOSTATUS(0),
+ .msg_stat = MAILBOX_MSGSTATUS(0),
+ },
+ .rx_fifo = {
+ .msg= MAILBOX_MESSAGE(1),
+ .msg_stat = MAILBOX_MSGSTATUS(1),
+ },
+ .irqenable = OMAP4_MAILBOX_IRQENABLE(3),
+ .irqstatus = OMAP4_MAILBOX_IRQSTATUS(3),
+ .irqdisable = OMAP4_MAILBOX_IRQENABLE_CLR(3),
+ .notfull_bit= MAILBOX_IRQ_NOTFULL(0),
+ .newmsg_bit = MAILBOX_IRQ_NEWMSG(0),
+};
+
+struct mailbox mbox_wkup_m3_info = {
+ .name = wkup_m3,
+ .ops= omap2_mbox_ops,
+ .priv = omap2_mbox_wkup_m3_priv,
+};
+struct mailbox *am33xx_mboxes[] = { mbox_wkup_m3_info, NULL };
+#endif
+
static int __devinit omap2_mbox_probe(struct platform_device *pdev)
{
struct resource *mem;
@@ -386,6 +412,13 @@ static int __devinit omap2_mbox_probe(struct
platform_device *pdev)
list[0]-irq = list[1]-irq = platform_get_irq(pdev, 0);
}
#endif
+#if defined(CONFIG_SOC_AM33XX)
ifdef in middle of the code. I know you are just
following what is already there.
+ else if (soc_is_am33xx()) {
+ list = am33xx_mboxes;
+
UN-necessary extra line here.
+ list[0]-irq = platform_get_irq(pdev, 0);
+ }
+#endif
Hopefully mailbox clean-up will kill that #ifdeffery.
Apart from those comments, patch looks fine to me.
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 v2 02/18] mailbox: Add an API for flushing the FIFO
On Monday 31 December 2012 06:36 PM, Vaibhav Bedia wrote:
On AM33XX, the mailbox module between the MPU and the
WKUP-M3 co-processor facilitates a one-way communication.
MPU uses the assigned mailbox sub-module to issue the
interrupt to the WKUP-M3 co-processor which then goes
and reads the the IPC data from registers in the control
module.
WKUP-M3 is in the L4_WKUP and does not have any access to
the mailbox module. Due to this limitation, the MPU is
completely responsible for FIFO maintenance and interrupt
generation. MPU needs to ensure that the FIFO does not
overflow by reading back the assigned mailbox sub-module.
This patch adds an API in the mailbox code which the MPU
can use to empty the FIFO by issuing a readback command.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
Note: This patch which will be slightly reworked once the mailbox
driver changes are finalized.
Can you expand a bit please ?
drivers/mailbox/mailbox-omap2.c | 19 +++
drivers/mailbox/mailbox.c | 36
drivers/mailbox/mailbox.h |3 +++
include/linux/mailbox.h |1 +
4 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/drivers/mailbox/mailbox-omap2.c b/drivers/mailbox/mailbox-omap2.c
index 6d61159..c732be1 100644
--- a/drivers/mailbox/mailbox-omap2.c
+++ b/drivers/mailbox/mailbox-omap2.c
@@ -125,6 +125,23 @@ static int omap2_mbox_fifo_full(struct mailbox *mbox)
return mbox_read_reg(fifo-fifo_stat);
}
+static int omap2_mbox_fifo_needs_flush(struct mailbox *mbox)
+{
+ struct omap_mbox2_priv *p = mbox-priv;
+ struct omap_mbox2_fifo *fifo = p-tx_fifo;
+
+ return mbox_read_reg(fifo-msg_stat);
+}
+
+static void omap2_mbox_fifo_readback(struct mailbox *mbox,
+ struct mailbox_msg *msg)
+{
+ struct omap_mbox2_priv *p = mbox-priv;
+ struct omap_mbox2_fifo *fifo = p-tx_fifo;
+
+ msg-header = mbox_read_reg(fifo-msg);
+}
+
static int ompa2_mbox_poll_for_space(struct mailbox *mbox)
{
if (omap2_mbox_fifo_full(mbox))
@@ -221,6 +238,8 @@ static struct mailbox_ops omap2_mbox_ops = {
.read = omap2_mbox_fifo_read,
.write = omap2_mbox_fifo_write,
.empty = omap2_mbox_fifo_empty,
+ .fifo_needs_flush = omap2_mbox_fifo_needs_flush,
+ .fifo_readback = omap2_mbox_fifo_readback,
.poll_for_space = ompa2_mbox_poll_for_space,
.enable_irq = omap2_mbox_enable_irq,
.disable_irq= omap2_mbox_disable_irq,
diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
index 2f50226..92c9f68 100644
--- a/drivers/mailbox/mailbox.c
+++ b/drivers/mailbox/mailbox.c
@@ -57,6 +57,15 @@ static inline int mbox_empty(struct mailbox *mbox)
{
return mbox-ops-empty(mbox);
}
+static inline int mbox_fifo_needs_flush(struct mailbox *mbox)
+{
+ return mbox-ops-fifo_needs_flush(mbox);
+}
+static inline void mbox_fifo_readback(struct mailbox *mbox,
+ struct mailbox_msg *msg)
+{
+ mbox-ops-fifo_readback(mbox, msg);
+}
/* Mailbox IRQ handle functions */
static inline void ack_mbox_irq(struct mailbox *mbox, mailbox_irq_t irq)
@@ -110,6 +119,33 @@ out:
}
EXPORT_SYMBOL(mailbox_msg_send);
+/*
s/*/**
+ * Flush the Rx FIFO by reading back the messages
+ * Since the normal expectation is that the Rx will do the
+ * reading, add a debug message to indicate if we really flush
+ *
+ * Returns the no. of messages read back
+ */
Just look at the kernel doc style for above
Rest looks fine.
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 v2 03/18] memory: emif: Move EMIF related header file to include/linux/
On Monday 31 December 2012 06:36 PM, Vaibhav Bedia wrote:
OMAP4 and AM33XX share the same EMIF controller IP. Although there
are significant differences in the IP integration due to which
AM33XX can't reuse the EMIF driver DVFS similar to OMAP4,
it can definitely benefit by reusing the EMIF related macros
defined in drivers/memory/emif.h.
In the current OMAP PM framework the PM code resides under
arch/arm/mach-omap2/. To enable reuse of the register defines move
the emif header file to include/linux so that both the EMIF driver
and the AM33XX PM code can benefit.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Aneesh V ane...@ti.com
---
v1-v2:
This is a new patch in the series to enable code reuse
between the EMIF driver and AM33XX PM code
drivers/memory/emif.c |2 +-
drivers/memory/emif.h | 589 ---
include/linux/ti_emif.h | 589 +++
You are just moving the file. So git mv file1 flie2; and the git
format-patch -C
on committed patch should just generate few lines of patch.
+/* DDR_PHY_CTRL_1 - EMIF4D5 */
+#define DLL_HALF_DELAY_SHIFT_4D5 21
+#define DLL_HALF_DELAY_MASK_4D5(1 21)
+#define READ_LATENCY_SHIFT_4D5 0
+#define READ_LATENCY_MASK_4D5 (0x1f 0)
+
+/* DDR_PHY_CTRL_1_SHDW */
+#define DDR_PHY_CTRL_1_SHDW_SHIFT 5
+#define DDR_PHY_CTRL_1_SHDW_MASK (0x7ff 5)
+#define READ_LATENCY_SHDW_SHIFT0
+#define READ_LATENCY_SHDW_MASK (0x1f 0)
+
+#ifndef __ASSEMBLY__
+/*
+ * Structure containing shadow of important registers in EMIF
+ * The calculation function fills in this structure to be later used for
+ * initialisation and DVFS
+ */
+struct emif_regs {
Are you using above struct. If not we can leave it in same place and
just move the register defines.
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
[PATCH 5/5] kfifo: log based kfifo API
The current kfifo API take the kfifo size as input, while it rounds
_down_ the size to power of 2 at __kfifo_alloc. This may introduce
potential issue.
Take the code at drivers/hid/hid-logitech-dj.c as example:
if (kfifo_alloc(djrcv_dev-notif_fifo,
DJ_MAX_NUMBER_NOTIFICATIONS * sizeof(struct dj_report),
GFP_KERNEL)) {
Where, DJ_MAX_NUMBER_NOTIFICATIONS is 8, and sizeo of(struct dj_report)
is 15.
Which means it wants to allocate a kfifo buffer which can store 8
dj_report entries at once. The expected kfifo buffer size would be
8 * 15 = 120 then. While, in the end, __kfifo_alloc will turn the
size to rounddown_power_of_2(120) = 64, and then allocate a buf
with 64 bytes, which I don't think this is the original author want.
With the new log API, we can do like following:
int kfifo_size_order = order_base_2(DJ_MAX_NUMBER_NOTIFICATIONS *
sizeof(struct dj_report));
if (kfifo_alloc(djrcv_dev-notif_fifo, kfifo_size_order, GFP_KERNEL)) {
This make sure we will allocate enough kfifo buffer for holding
DJ_MAX_NUMBER_NOTIFICATIONS dj_report entries.
Cc: Stefani Seibold stef...@seibold.net
Cc: Andrew Morton a...@linux-foundation.org
Cc: linux-omap@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: platform-driver-...@vger.kernel.org
Cc: linux-in...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-r...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-...@lists.infradead.org
Cc: libertas-...@lists.infradead.org
Cc: linux-wirel...@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: open-is...@googlegroups.com
Cc: linux-s...@vger.kernel.org
Cc: de...@driverdev.osuosl.org
Cc: linux-ser...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux...@kvack.org
Cc: d...@vger.kernel.org
Cc: linux-s...@vger.kernel.org
Signed-off-by: Yuanhan Liu yuanhan@linux.intel.com
---
arch/arm/plat-omap/Kconfig |2 +-
arch/arm/plat-omap/mailbox.c|6 +++-
arch/powerpc/sysdev/fsl_rmu.c |2 +-
drivers/char/sonypi.c |9 ---
drivers/hid/hid-logitech-dj.c |7 +++--
drivers/iio/industrialio-event.c|2 +-
drivers/iio/kfifo_buf.c |3 +-
drivers/infiniband/hw/cxgb3/cxio_resource.c |8 --
drivers/media/i2c/cx25840/cx25840-ir.c |9 +--
drivers/media/pci/cx23885/cx23888-ir.c |9 +--
drivers/media/pci/meye/meye.c |6 +---
drivers/media/pci/meye/meye.h |2 +
drivers/media/rc/ir-raw.c |7 +++--
drivers/memstick/host/r592.h|2 +-
drivers/mmc/card/sdio_uart.c|4 ++-
drivers/mtd/sm_ftl.c|5 +++-
drivers/net/wireless/libertas/main.c|4 ++-
drivers/net/wireless/rt2x00/rt2x00dev.c |5 +--
drivers/pci/pcie/aer/aerdrv_core.c |3 +-
drivers/platform/x86/fujitsu-laptop.c |5 ++-
drivers/platform/x86/sony-laptop.c |6 ++--
drivers/rapidio/devices/tsi721.c|5 ++-
drivers/scsi/libiscsi_tcp.c |6 +++-
drivers/staging/omapdrm/omap_plane.c|5 +++-
drivers/tty/n_gsm.c |4 ++-
drivers/tty/nozomi.c|5 +--
drivers/tty/serial/ifx6x60.c|2 +-
drivers/tty/serial/ifx6x60.h|3 +-
drivers/tty/serial/kgdb_nmi.c |7 +++--
drivers/usb/host/fhci.h |4 ++-
drivers/usb/serial/cypress_m8.c |4 +-
drivers/usb/serial/io_ti.c |4 +-
drivers/usb/serial/ti_usb_3410_5052.c |7 +++--
drivers/usb/serial/usb-serial.c |2 +-
include/linux/kfifo.h | 31 +--
include/linux/rio.h |1 +
include/media/lirc_dev.h|4 ++-
kernel/kfifo.c |9 +--
mm/memory-failure.c |3 +-
net/dccp/probe.c|6 +++-
net/sctp/probe.c|6 +++-
samples/kfifo/bytestream-example.c |8 +++---
samples/kfifo/dma-example.c |5 ++-
samples/kfifo/inttype-example.c |7 +++--
samples/kfifo/record-example.c |6 ++--
45 files changed, 142 insertions(+), 108 deletions(-)
diff --git a/arch/arm/plat-omap/Kconfig b/arch/arm/plat-omap/Kconfig
index 665870d..7eda02c 100644
--- a/arch/arm/plat-omap/Kconfig
+++ b/arch/arm/plat-omap/Kconfig
@@ -124,7 +124,7 @@ config OMAP_MBOX_FWK
DSP, IVA1.0 and IVA2 in OMAP1/2/3.
config OMAP_MBOX_KFIFO_SIZE
- int Mailbox kfifo default buffer size (bytes)
+ int Mailbox kfifo default buffer size (bytes,
Re: [RFC v2 04/18] ARM: OMAP2+: AM33XX: CM: Get rid of unncessary header inclusions
On Monday 31 December 2012 06:36 PM, Vaibhav Bedia wrote: Some of the included header files are not needed so remove them. Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Vaibhav Hiremath hvaib...@ti.com --- 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
Re: [RFC v2 05/18] ARM: OMAP2+: AM33XX: CM/PRM: Use __ASSEMBLER__ macros in header files
On Monday 31 December 2012 06:36 PM, Vaibhav Bedia wrote: This is necessary to ensure that macros declared here can be reused from assembly files. Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Benoit Cousson b-cous...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Vaibhav Hiremath hvaib...@ti.com --- v1-v2: Split out the header file changes in a separate patch based on the feedback from Santosh arch/arm/mach-omap2/cm33xx.h |3 +++ arch/arm/mach-omap2/prm33xx.h |3 +++ 2 files changed, 6 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/cm33xx.h b/arch/arm/mach-omap2/cm33xx.h index 8009e13..2f215cd 100644 --- a/arch/arm/mach-omap2/cm33xx.h +++ b/arch/arm/mach-omap2/cm33xx.h @@ -376,6 +376,7 @@ #define AM33XX_CM_CEFUSE_CEFUSE_CLKCTRL AM33XX_CM_REGADDR(AM33XX_CM_CEFUSE_MOD, 0x0020) +#ifndef __ASSEMBLER__ extern bool am33xx_cm_is_clkdm_in_hwsup(s16 inst, u16 cdoffs); extern void am33xx_cm_clkdm_enable_hwsup(s16 inst, u16 cdoffs); extern void am33xx_cm_clkdm_disable_hwsup(s16 inst, u16 cdoffs); @@ -412,4 +413,6 @@ static inline int am33xx_cm_wait_module_ready(u16 inst, s16 cdoffs, } #endif +#endif /* ASSEMBLER */ + Drop that extra line. #endif diff --git a/arch/arm/mach-omap2/prm33xx.h b/arch/arm/mach-omap2/prm33xx.h index 3f25c56..2f2eaa0 100644 --- a/arch/arm/mach-omap2/prm33xx.h +++ b/arch/arm/mach-omap2/prm33xx.h @@ -117,6 +117,7 @@ #define AM33XX_PM_CEFUSE_PWRSTST_OFFSET 0x0004 #define AM33XX_PM_CEFUSE_PWRSTST AM33XX_PRM_REGADDR(AM33XX_PRM_CEFUSE_MOD, 0x0004) +#ifndef __ASSEMBLER__ extern u32 am33xx_prm_read_reg(s16 inst, u16 idx); extern void am33xx_prm_write_reg(u32 val, s16 inst, u16 idx); extern u32 am33xx_prm_rmw_reg_bits(u32 mask, u32 bits, s16 inst, s16 idx); @@ -126,4 +127,6 @@ extern int am33xx_prm_is_hardreset_asserted(u8 shift, s16 inst, extern int am33xx_prm_assert_hardreset(u8 shift, s16 inst, u16 rstctrl_offs); extern int am33xx_prm_deassert_hardreset(u8 shift, s16 inst, u16 rstctrl_offs, u16 rstst_offs); +#endif /* ASSEMBLER */ + ditto Otherwise looks fine. 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
Re: [RFC v2 06/18] ARM: OMAP2+: AM33XX: hwmod: Register OCMC RAM hwmod
On Monday 31 December 2012 06:36 PM, Vaibhav Bedia wrote: OCMC RAM lies in the PER power domain and this memory support retention. Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Vaibhav Hiremath hvaib...@ti.com --- Looks fine to me. 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
Re: [RFC v2 07/18] ARM: OMAP2+: AM33XX: hwmod: Update TPTC0 hwmod with the right flags
On Monday 31 December 2012 06:37 PM, Vaibhav Bedia wrote: TPTC0 needs to be idled and put to standby under SW control. Add the appropriate flags in the TPTC0 hwmod entry. Can you please expand TPTC0 in chane log. Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Vaibhav Hiremath hvaib...@ti.com --- Patch is fine otherwise. 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
Re: [RFC v2 08/18] ARM: OMAP2+: AM33XX: hwmod: Fixup cpgmac0 hwmod entry
On Monday 31 December 2012 06:37 PM, Vaibhav Bedia wrote: The current HWMOD code expects the memory region with the IP's SYSCONFIG register to be marked with ADDR_TYPE_RT flag. CPGMAC0 hwmod entry specifies two memory regions and marks both with the flag ADDR_TYPE_RT although only the 2nd region has the SYSCONFIG register. This leads to the HWMOD code accessing the wrong memory address for idle and standby operations. Fix this by removing the ADDR_TYPE_RT flag from the 1st memory region in CPGMAC0 hwmod entry. Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Vaibhav Hiremath hvaib...@ti.com --- Seems correct to me though Benoit, Paul can may have comment. 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 v2 09/18] ARM: OMAP2+: AM33XX: hwmod: Update the WKUP-M3 hwmod with reset status bit
Vaibhav, On Monday 31 December 2012 06:37 PM, Vaibhav Bedia wrote: WKUP-M3 has a reset status bit (RM_WKUP_STST.WKUP_M3_LRST) Update the WKUP-M3 hwmod data to reflect the same. Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Vaibhav Hiremath hvaib...@ti.com --- I think you should make a separate series for the data file updates/fixes. 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 v2 10/18] ARM: OMAP2+: AM33XX: Update the hardreset API
On Monday 31 December 2012 06:37 PM, Vaibhav Bedia wrote: WKUP-M3 has a reset status bit (RM_WKUP_STST.WKUP_M3_LRST) Update the hardreset API to ensure that the reset line properly deasserted. Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Vaibhav Hiremath hvaib...@ti.com --- Looks good. 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
Re: [RFC v2 11/18] ARM: DTS: AM33XX: Add nodes for OCMC RAM and WKUP-M3
On Monday 31 December 2012 06:37 PM, Vaibhav Bedia wrote: Since AM33XX supports only DT-boot, this is needed for the appropriate device nodes to be created. Note: OCMC RAM is part of the PER power domain and supports retention. The assembly code for low power entry/exit will run from OCMC RAM. To ensure that the OMAP PM code does not attempt to disable the clock to OCMC RAM as part of the suspend process add the no_idle_on_suspend flag. Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com Cc: Tony Lindgren t...@atomide.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Vaibhav Hiremath hvaib...@ti.com --- Looks fine to me. 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
Re: [RFC v2 12/18] ARM: OMAP2+: timer: Add suspend-resume callbacks for clockevent device
On Monday 31 December 2012 06:37 PM, Vaibhav Bedia wrote:
The current OMAP timer code registers two timers -
one as clocksource and one as clockevent.
AM33XX has only one usable timer in the WKUP domain
so one of the timers needs suspend-resume support
to restore the configuration to pre-suspend state.
commit adc78e6 (timekeeping: Add suspend and resume
of clock event devices) introduced .suspend and .resume
callbacks for clock event devices. Leverages these
callbacks to have AM33XX clockevent timer which is
in not in WKUP domain to behave properly across system
suspend.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Vaibhav Hiremath hvaib...@ti.com
Cc: Jon Hunter jon-hun...@ti.com
---
v1-v2:
Get rid of harcoded timer id.
Note: since a platform device is not created for these timer
instances and because there's very minimal change needed for
restarting the timer a full blown context save and restore
has been skipped.
arch/arm/mach-omap2/timer.c | 33 +
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index 691aa67..38f9cbc 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -128,6 +128,36 @@ static void omap2_gp_timer_set_mode(enum clock_event_mode
mode,
}
}
+static void omap_clkevt_suspend(struct clock_event_device *unused)
+{
+ char name[10];
+ struct omap_hwmod *oh;
+
+ sprintf(name, timer%d, clkev.id);
+ oh = omap_hwmod_lookup(name);
+ if (!oh)
+ return;
+
+ __omap_dm_timer_stop(clkev, 1, clkev.rate);
+ omap_hwmod_idle(oh);
+}
+
+static void omap_clkevt_resume(struct clock_event_device *unused)
+{
+ char name[10];
+ struct omap_hwmod *oh;
+
+ sprintf(name, timer%d, clkev.id);
+ oh = omap_hwmod_lookup(name);
+ if (!oh)
+ return;
+
+ omap_hwmod_enable(oh);
+ __omap_dm_timer_load_start(clkev,
+ OMAP_TIMER_CTRL_ST | OMAP_TIMER_CTRL_AR, 0, 1);
+ __omap_dm_timer_int_enable(clkev, OMAP_TIMER_INT_OVERFLOW);
+}
+
Am still bit uncomfortable with direct hwmod usage in the suspend/resmue
hooks.
Jon, Any alternatives you can think of ?
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 v2 13/18] ARM: OMAP2+: AM33XX: timer: Interchance clkevt and clksrc timers
On Monday 31 December 2012 06:37 PM, Vaibhav Bedia wrote: AM33XX has two timers (DTIMER0/1) in the WKUP domain. On GP devices the source of DMTIMER0 is fixed to an inaccurate internal 32k RC oscillator and this makes the DMTIMER0 practically either as a clocksource or as clockevent. Currently the timer instance in WKUP domain is used as the clockevent and the timer in non-WKUP domain as the clocksource. DMTIMER1 in WKUP domain can keep running in suspend from a 32K clock fed from external OSC and can serve as the persistent clock for the kernel. To enable this, interchange the timers used as clocksource and clockevent for AM33XX. For now a new DT property has been added to allow the timer code to select the timer with the right property. It has been pointed out by Santosh Shilimkar and Kevin Hilman that such a change will result in soc-idle never being achieved on AM33XX. There are other reasons why soc-idle does not look feasible on AM33XX so for now we go ahead with the interchange of the the timers. If at a later point of time we do come up with an approach which makes soc-idle possible on AM33XX, this can be revisited. Can you please explain other reasons as well for clarity ? 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 v2 14/18] ARM: OMAP2+: AM33XX: control: Add some control module registers and APIs
On Monday 31 December 2012 06:37 PM, Vaibhav Bedia wrote: Add minimal APIs for writing to the IPC and the M3_TXEV registers in the Control module. These will be used in a subsequent patch which adds suspend-resume support for AM33XX. Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com Cc: Tony Lingren t...@atomide.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Vaibhav Hiremath hvaib...@ti.com --- On Control module, we are trying to move driver/module specific code to respective drivers. Can you not add below code to ipc related driver component. If not, then patch as such is fine with me. 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 v2 17/18] ARM: OMAP2+: AM33XX: Select Mailbox when PM is enabled
On Monday 31 December 2012 06:37 PM, Vaibhav Bedia wrote: PM services on AM33XX depend on mailbox for communication with WKUP-M3 core so ensure that the right config options are selected. Thanks to Kevin Hilman khil...@deeprootsystems.com for the suggestion on updating the Kconfig and not just the omap2plus_defconfig which was done in the previous version of the AM33XX suspend-resume support. Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com Cc: Tony Lingren t...@atomide.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@deeprootsystems.com --- Unrelated to series. You can post this patch separately. 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 v2 00/18] ARM: OMAP2+: AM33XX: Add suspend-resume support
Vaibhav, On Monday 31 December 2012 06:36 PM, Vaibhav Bedia wrote: Hi, This is the second version of the patch series for adding suspend-resume support for AM33XX. Based on the feedback received on the previous patch series [1] almost all the patches have undergone a bit a rework. The 1st two patches depend on the changes for mailbox code migration from arch/arm/*-omap*/ to drivers/mailbox/ [2]. The patch series also depends on recent changes to the OMAP PM framework by Paul Walmsley. I found it easiest to apply the AM33XX suspend-resume patches on top of Paul's TEST_pwrdm_post_fpwrst_devel_a_3.9 branch + the patches @ [2]. With these dependencies met, the PM code uses the firmware interface and expects the userspace to load the WKUP_M3 binary before the suspend-resume functionality is made available. The binary file (and the source-code for WKUP_M3) can be obtained from the 'next' branch at [3]. The WKUP_M3 binary can either be loaded post bootup via the sysfs entry './sys/devices/ocp.2/wkup_m3.4/firmware' or it can be included in the kernel image as part of the build process. DDR3 specific changes have been skipped for now since mainline U-Boot exhibited stability issues on all the DDR3 based AM335x boards that i could lay my hands on. I have done basic testing along with power measurments on the different power rails on the AM335x EVM. PER domain transition on the BeagleBone fails if the CPSW driver is included in the kernel and is yet to be root caused. Along with this issue more extensive testing on other OMAP platforms is also pending right now. For more details on the AM335x suspend-resume support please refer to the changelog in the different patches. I still haven't reviewed patch 15, 16 and 18 which adds suspend support. Will do that in coming days since they need a bit a closer look. But as mentioned in some of the patches, you need to split this series since except 15, 16 and 18 which adds suspend support, rest of the patches are - data file fixes - timer suspend/resume update - mailbox support, control module update. Would be good to split the series to help the reviews. 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 RESEND] ARM: dts: AM33XX: Rename I2C and GPIO nodes
Hi Anil, On 01/02/2013 11:12 AM, AnilKumar, Chimata wrote: On Wed, Nov 21, 2012 at 17:22:17, AnilKumar, Chimata wrote: Rename I2C and GPIO nodes according to AM33XX TRM. According to AM33XX TRM device instances are starting from 0 like i2c0, i2c1 and i2c3. Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com [pa...@antoniou-consulting.com: initial patch by pantelis's] Signed-off-by: AnilKumar Ch anilku...@ti.com --- Changes from first version: - Updated pantelis's patch * Modified based on linux-omap/master * Added GPIO nodes renaming as well Hi Tony/Benoit, If there are no comments could you please pull this patch? Yep, it is done. The patch is available here: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.9/dts 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 1/5] capemgr: Beaglebone DT overlay based cape manager
On Tuesday 08 January 2013, Pantelis Antoniou wrote: On Jan 8, 2013, at 2:12 PM, Arnd Bergmann wrote: On Tuesday 08 January 2013, Lee Jones wrote: If there is not, there is no way to automatically load the overlays; you can always use the kernel command line, or have the a user space application to request the loading of a specific board's overlay. Unfortunately, there is no way to probe the UIBs. :( I thought that some of the newer UIBs had it, just not the old ones. As Pantelis says, we could at least detect the ones that have an EEPROM on them, and use a command line option or device tree attribute for the others. Arnd So I gather the new ones have an eeprom? I don't remember the details unfortunately. Lee should be the one who can find out. IIRC there was at least a single integeger number on them. Arnd -- 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 v4 0/3] ARM/dts: omap3: Add DT support for IGEP devices
Hi Javier, On 12/19/2012 02:33 PM, Javier Martinez Canillas wrote: IGEP technology devices are TI OMAP3 SoC based industrial embedded and computer-on-module boards. This patch-set adds initial device tree support for these devices. The device trees allows to boot from an MMC and are working all the components that already have device tree support on OMAP3 SoCs: - MMC/SD - UARTs - GPIO LEDs - TWL4030 codec audio - pinmux/pinconf pinctrl Some peripheral are still not working such as Flash storage and Ethernet but support for these will also be included once the OMAP GPMC device tree binding patches land on mainline. This is a v4 of the patch-set that adds MMC mux pins setup and fixes a build issue due recent changes on twl4030.dtsi. The patch-set is composed of the following patches: [PATCH v4 1/3] ARM/dts: omap3: Add generic DT support for IGEP devices [PATCH v4 2/3] ARM/dts: omap3: Add support for IGEPv2 board [PATCH v4 3/3] ARM/dts: omap3: Add support for IGEP COM Module I've just applied your series for 3.9 on top of 3.8-rc2 and had to update the Makefile that was different in the base you used. At the same time I updated the subjects to use ARM: dts: prefix to be compliant with the latest trend :-) The patches are available here: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.9/dts 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 v4 0/3] ARM/dts: omap3: Add DT support for IGEP devices
On Tue, Jan 8, 2013 at 5:13 PM, Benoit Cousson b-cous...@ti.com wrote: Hi Javier, On 12/19/2012 02:33 PM, Javier Martinez Canillas wrote: IGEP technology devices are TI OMAP3 SoC based industrial embedded and computer-on-module boards. This patch-set adds initial device tree support for these devices. The device trees allows to boot from an MMC and are working all the components that already have device tree support on OMAP3 SoCs: - MMC/SD - UARTs - GPIO LEDs - TWL4030 codec audio - pinmux/pinconf pinctrl Some peripheral are still not working such as Flash storage and Ethernet but support for these will also be included once the OMAP GPMC device tree binding patches land on mainline. This is a v4 of the patch-set that adds MMC mux pins setup and fixes a build issue due recent changes on twl4030.dtsi. The patch-set is composed of the following patches: [PATCH v4 1/3] ARM/dts: omap3: Add generic DT support for IGEP devices [PATCH v4 2/3] ARM/dts: omap3: Add support for IGEPv2 board [PATCH v4 3/3] ARM/dts: omap3: Add support for IGEP COM Module I've just applied your series for 3.9 on top of 3.8-rc2 and had to update the Makefile that was different in the base you used. At the same time I updated the subjects to use ARM: dts: prefix to be compliant with the latest trend :-) The patches are available here: git://git.kernel.org/pub/scm/linux/kernel/git/bcousson/linux-omap-dt.git for_3.9/dts Regards, Benoit -- Great, thanks a lot Benoit! Best regards, Javier -- 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] few omap fixes for v3.8-rc2
The following changes since commit d1c3ed669a2d452cacfb48c2d171a1f364dae2ed: Linux 3.8-rc2 (2013-01-02 18:13:21 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.8-rc2/fixes-signed-v2 for you to fetch changes up to 6adba67eb0c4731ed0346731d024b2102f5b4d9d: ARM: OMAP2+: am33xx-hwmod: Fix wrongly terminated am33xx_usbss_mpu_irqs array (2013-01-07 12:38:07 -0800) The biggest change is a fix to deal with different power state on omap2 registers that causes issues trying to use common PM code. Also fix few incorrect registers, and an issue for omap1 USB, and few sparse fixes for issues that sneaked in with all the clean-up. Aaro Koskinen (1): ARM: OMAP1: fix USB configuration use-after-release Ivan Khoronzhuk (2): ARM: OMAP4: PRM: Correct reset source map ARM: OMAP4: PRM: Correct wrong instance usage for reading reset sources Jon Hunter (1): ARM: OMAP3: clock data: Add missing enable/disable for EMU clock Nishanth Menon (1): ARM: OMAP4: PRM: fix RSTTIME and RSTST offsets Pantelis Antoniou (1): ARM: OMAP2+: am33xx-hwmod: Fix wrongly terminated am33xx_usbss_mpu_irqs array Paul Walmsley (4): ARM: OMAP: 32k counter: resolve sparse warnings ARM: OMAP AM33xx: hwmod data: resolve sparse warnings ARM: OMAP: SRAM: resolve sparse warnings ARM: OMAP2/3: PRM: fix bogus OMAP2xxx powerstate return values Tony Lindgren (1): Merge tag 'omap-fixes-a2-for-v3.8-rc' of git://git.kernel.org/.../pjw/omap-pending into omap-for-v3.8-rc2/fixes arch/arm/mach-omap1/board-ams-delta.c | 2 +- arch/arm/mach-omap1/usb.c | 8 ++- arch/arm/mach-omap2/cclock3xxx_data.c | 2 + arch/arm/mach-omap2/omap_hwmod_33xx_data.c | 6 +- arch/arm/mach-omap2/prm2xxx.c | 88 +- arch/arm/mach-omap2/prm2xxx_3xxx.c | 22 arch/arm/mach-omap2/prm3xxx.c | 28 +- arch/arm/mach-omap2/prm44xx.c | 6 +- arch/arm/mach-omap2/prm44xx.h | 4 +- arch/arm/plat-omap/counter_32k.c | 2 + arch/arm/plat-omap/sram.c | 2 + 11 files changed, 132 insertions(+), 38 deletions(-) -- 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: [GIT PULL] few omap fixes for v3.8-rc2
On Tue, Jan 8, 2013 at 9:48 AM, Tony Lindgren t...@atomide.com wrote: The following changes since commit d1c3ed669a2d452cacfb48c2d171a1f364dae2ed: Linux 3.8-rc2 (2013-01-02 18:13:21 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.8-rc2/fixes-signed-v2 for you to fetch changes up to 6adba67eb0c4731ed0346731d024b2102f5b4d9d: ARM: OMAP2+: am33xx-hwmod: Fix wrongly terminated am33xx_usbss_mpu_irqs array (2013-01-07 12:38:07 -0800) The biggest change is a fix to deal with different power state on omap2 registers that causes issues trying to use common PM code. Also fix few incorrect registers, and an issue for omap1 USB, and few sparse fixes for issues that sneaked in with all the clean-up. Pulled, thanks. Not super-happy about the 100+ line delta for the 24xx bugfix, but seems like it's needed. -Olof -- 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 5/5] kfifo: log based kfifo API
Hi Yuanhan,
On Tue, Jan 08, 2013 at 10:57:53PM +0800, Yuanhan Liu wrote:
The current kfifo API take the kfifo size as input, while it rounds
_down_ the size to power of 2 at __kfifo_alloc. This may introduce
potential issue.
Take the code at drivers/hid/hid-logitech-dj.c as example:
if (kfifo_alloc(djrcv_dev-notif_fifo,
DJ_MAX_NUMBER_NOTIFICATIONS * sizeof(struct dj_report),
GFP_KERNEL)) {
Where, DJ_MAX_NUMBER_NOTIFICATIONS is 8, and sizeo of(struct dj_report)
is 15.
Which means it wants to allocate a kfifo buffer which can store 8
dj_report entries at once. The expected kfifo buffer size would be
8 * 15 = 120 then. While, in the end, __kfifo_alloc will turn the
size to rounddown_power_of_2(120) = 64, and then allocate a buf
with 64 bytes, which I don't think this is the original author want.
With the new log API, we can do like following:
int kfifo_size_order = order_base_2(DJ_MAX_NUMBER_NOTIFICATIONS *
sizeof(struct dj_report));
if (kfifo_alloc(djrcv_dev-notif_fifo, kfifo_size_order, GFP_KERNEL)) {
This make sure we will allocate enough kfifo buffer for holding
DJ_MAX_NUMBER_NOTIFICATIONS dj_report entries.
Why don't you simply change __kfifo_alloc to round the allocation up
instead of down?
Thanks.
--
Dmitry
--
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: [GIT PULL] few omap fixes for v3.8-rc2
* Olof Johansson o...@lixom.net [130108 10:04]: On Tue, Jan 8, 2013 at 9:48 AM, Tony Lindgren t...@atomide.com wrote: The following changes since commit d1c3ed669a2d452cacfb48c2d171a1f364dae2ed: Linux 3.8-rc2 (2013-01-02 18:13:21 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap tags/omap-for-v3.8-rc2/fixes-signed-v2 for you to fetch changes up to 6adba67eb0c4731ed0346731d024b2102f5b4d9d: ARM: OMAP2+: am33xx-hwmod: Fix wrongly terminated am33xx_usbss_mpu_irqs array (2013-01-07 12:38:07 -0800) The biggest change is a fix to deal with different power state on omap2 registers that causes issues trying to use common PM code. Also fix few incorrect registers, and an issue for omap1 USB, and few sparse fixes for issues that sneaked in with all the clean-up. Pulled, thanks. Not super-happy about the 100+ line delta for the 24xx bugfix, but seems like it's needed. Yes sorry looks like Paul was attempting to drop the omap custom PM changes related to the drivers/i2c/bus/i2c-omap.c revert mess, but naturally it's now too late. AFAIK that patch could wait for v3.9 too if necessary. 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
Re: [PATCH v2 3/3] usb: musb: omap: Add device tree support for omap musb glue
Hello.
On 09/11/2012 01:09 PM, Kishon Vijay Abraham I wrote:
Added device tree support for omap musb driver and updated the
Documentation with device tree binding information.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Belated comments to the patch which didn't pass my message size filter in
time. :-)
diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
index f4d9503..d96873b 100644
--- a/drivers/usb/musb/omap2430.c
+++ b/drivers/usb/musb/omap2430.c
[...]
@@ -470,8 +471,11 @@ static u64 omap2430_dmamask = DMA_BIT_MASK(32);
static int __devinit omap2430_probe(struct platform_device *pdev)
{
struct musb_hdrc_platform_data *pdata = pdev-dev.platform_data;
+ struct omap_musb_board_data *data;
struct platform_device *musb;
struct omap2430_glue*glue;
+ struct device_node *np = pdev-dev.of_node;
+ struct musb_hdrc_config *config;
struct resource *res;
int ret = -ENOMEM;
@@ -501,6 +505,42 @@ static int __devinit omap2430_probe(struct
platform_device *pdev)
if (glue-control_otghs == NULL)
dev_dbg(pdev-dev, Failed to obtain control memory\n);
+ if (np) {
+ pdata = devm_kzalloc(pdev-dev, sizeof(*pdata), GFP_KERNEL);
+ if (!pdata) {
+ dev_err(pdev-dev,
+ failed to allocate musb platfrom data\n);
+ ret = -ENOMEM;
'ret' is pre-initialized to -ENOMEM.
+ goto err1;
+ }
+
+ data = devm_kzalloc(pdev-dev, sizeof(*data), GFP_KERNEL);
+ if (!data) {
+ dev_err(pdev-dev,
+ failed to allocate musb board data\n);
Overindented this line.
+ ret = -ENOMEM;
Same comment about already pre-initialized variable.
+ goto err1;
+ }
+
+ config = devm_kzalloc(pdev-dev, sizeof(*config), GFP_KERNEL);
+ if (!data) {
You allocate 'config' but check 'data' again, so instead of exiting
gracefully we get an oops later on...
+ dev_err(pdev-dev,
+ failed to allocate musb hdrc config\n);
No 'ret = -ENOMEM;' here -- kinda inconsistent. :-)
+ goto err1;
+ }
+
+ of_property_read_u32(np, mode, (u32 *)pdata-mode);
+ of_property_read_u32(np, interface_type,
+ (u32 *)data-interface_type);
+ of_property_read_u32(np, num_eps, (u32 *)config-num_eps);
+ of_property_read_u32(np, ram_bits, (u32 *)config-ram_bits);
+ of_property_read_u32(np, power, (u32 *)pdata-power);
+ config-multipoint = of_property_read_bool(np, multipoint);
+
+ pdata-board_data = data;
+ pdata-config = config;
+ }
+
pdata-platform_ops = omap2430_ops;
platform_set_drvdata(pdev, glue);
Don't worry now, I've just sent two patches to address these shortcomings.
WBR, Sergei
--
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/2] omap2430: fix wrong devm_kzalloc() result check
Commit 00a0b1d58af873d842580dcac55f3b156c3a4077 (usb: musb: omap: Add device
tree support for omap musb glue) assigns result of devm_kzalloc() call to
the 'config' variable but then checks for NULL the 'data' variable (already
checked after previous call). Thus we risk a kernel oops further when data
pointed by 'config' is written to by subsequent of_property_read_u32() calls
iff the allocation happens to fail...
Signed-off-by: Sergei Shtylyov sshtyl...@ru.mvista.com
---
This patch is atop of 'musb' branch of Felipe's tree but can also be applied to
the 'fixes' branch.
drivers/usb/musb/omap2430.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: usb/drivers/usb/musb/omap2430.c
===
--- usb.orig/drivers/usb/musb/omap2430.c
+++ usb/drivers/usb/musb/omap2430.c
@@ -545,7 +545,7 @@ static int __devinit omap2430_probe(stru
}
config = devm_kzalloc(pdev-dev, sizeof(*config), GFP_KERNEL);
- if (!data) {
+ if (!config) {
dev_err(pdev-dev,
failed to allocate musb hdrc config\n);
goto err2;
--
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/2] omap2430: kill redundant assignments in omap2430_probe()
Commit 00a0b1d58af873d842580dcac55f3b156c3a4077 (usb: musb: omap: Add device
tree support for omap musb glue) added assignments of the 'ret' variable to
-ENOMEM on *some* error paths of the calls to devm_kzalloc(), while that
variable was already pre-initialized for to that value, so these assignments
were completely redundant. Kill them, fixing overindented string, while at it.
Signed-off-by: Sergei Shtylyov sshtyl...@ru.mvista.com
---
This patch is atop of 'musb' branch of Felipe's tree.
drivers/usb/musb/omap2430.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
Index: usb/drivers/usb/musb/omap2430.c
===
--- usb.orig/drivers/usb/musb/omap2430.c
+++ usb/drivers/usb/musb/omap2430.c
@@ -532,15 +532,13 @@ static int __devinit omap2430_probe(stru
if (!pdata) {
dev_err(pdev-dev,
failed to allocate musb platfrom data\n);
- ret = -ENOMEM;
goto err2;
}
data = devm_kzalloc(pdev-dev, sizeof(*data), GFP_KERNEL);
if (!data) {
dev_err(pdev-dev,
- failed to allocate musb board data\n);
- ret = -ENOMEM;
+ failed to allocate musb board data\n);
goto err2;
}
--
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 02/10] crypto: omap-aes - Don't reset controller for every operation
From: Mark A. Greer mgr...@animalcreek.com
The AES controller only needs to be reset once and that will
be done by the hwmod infrastructure, if possible. Therefore,
remove the reset code from the omap-aes driver.
CC: Dmitry Kasatkin dmitry.kasat...@intel.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
drivers/crypto/omap-aes.c | 27 ---
1 file changed, 27 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index 481da71..33cd783 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -160,19 +160,6 @@ static void omap_aes_write_n(struct omap_aes_dev *dd, u32
offset,
omap_aes_write(dd, offset, *value);
}
-static int omap_aes_wait(struct omap_aes_dev *dd, u32 offset, u32 bit)
-{
- unsigned long timeout = jiffies + DEFAULT_TIMEOUT;
-
- while (!(omap_aes_read(dd, offset) bit)) {
- if (time_is_before_jiffies(timeout)) {
- dev_err(dd-dev, omap-aes timeout\n);
- return -ETIMEDOUT;
- }
- }
- return 0;
-}
-
static int omap_aes_hw_init(struct omap_aes_dev *dd)
{
/*
@@ -183,20 +170,6 @@ static int omap_aes_hw_init(struct omap_aes_dev *dd)
clk_enable(dd-iclk);
if (!(dd-flags FLAGS_INIT)) {
- /* is it necessary to reset before every operation? */
- omap_aes_write_mask(dd, AES_REG_MASK, AES_REG_MASK_SOFTRESET,
- AES_REG_MASK_SOFTRESET);
- /*
-* prevent OCP bus error (SRESP) in case an access to the module
-* is performed while the module is coming out of soft reset
-*/
- __asm__ __volatile__(nop);
- __asm__ __volatile__(nop);
-
- if (omap_aes_wait(dd, AES_REG_SYSSTATUS,
- AES_REG_SYSSTATUS_RESETDONE))
- return -ETIMEDOUT;
-
dd-flags |= FLAGS_INIT;
dd-err = 0;
}
--
1.7.12
--
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 00/10] crypto: omap-aes - Updates New Functionality
From: Mark A. Greer mgr...@animalcreek.com Changes from v1: - Addressed comments by Russ Dill by defining omap_aes_of_match[] to contain an empty entry (end of list indicator) and defining omap_aes_get_res_of() instead of incorrectly defining omap_aes_get_res_dev() when CONFIG_OF is not defined. This patch series does several things to the omap-aes crypto driver including: - converting to use pm_runtime - adding suspend/resume support - converting to use dmaengine API - adding device tree support - adding OMAP4/AM33XX support - adding CTR support - some misc. cleanups The patches are based on the current k.o. 54e37b8 (Merge tag 'vfio-for-v3.8-v2' of git://github.com/awilliam/linux-vfio), plus: - the ARM hwmod, etc patches from [PATCH 00/15] OMAP SHAM AES Crypto Updates (http://marc.info/?l=linux-omapm=135610732120447w=2) - the EDMA dmaengine patches submitted by Matt Porter [RFC PATCH v3 00/16] DMA Engine support for AM33XX] (https://lkml.org/lkml/2012/10/18/256) - some misc patches required by the EDMA patches - a hack to fix the compilation error that the current k.o. kernel has A working examle is here: g...@github.com:mgreeraz/linux-mag.git submitted/crypto/aes This patch series does several things to the omap-aes crypto driver including: - converting to use pm_runtime - adding suspend/resume support - converting to use dmaengine API - adding device tree support - adding OMAP4/AM33XX support - adding CTR support - some misc. cleanups The patches are based on the current k.o. kernel, plus: - the ARM hwmod, etc patches from [PATCH 00/15] OMAP SHAM AES Crypto Updates (http://marc.info/?l=linux-omapm=135610732120447w=2) - the EDMA dmaengine patches submitted by Matt Porter [RFC PATCH v3 00/16] DMA Engine support for AM33XX] (https://lkml.org/lkml/2012/10/18/256) - some misc patches required by the EDMA patches - a hack to fix the compilation error that the current k.o. kernel has A working examle is here: g...@github.com:mgreeraz/linux-mag.git submitted/crypto/aes Mark A. Greer (10): crypto: omap-aes - Remmove unnecessary pr_info noise crypto: omap-aes - Don't reset controller for every operation crypto: omap-aes - Convert to use pm_runtime API crypto: omap-aes - Add suspend/resume support crypto: omap-aes - Add code to use dmaengine API crypto: omap-aes - Remove usage of private DMA API crypto: omap-aes - Add Device Tree Support crypto: omap-aes - Convert to dma_request_slave_channel_compat() crypto: omap-aes - Add OMAP4/AM33XX AES Support crypto: omap-aes - Add CTR algorithm Support drivers/crypto/omap-aes.c | 658 ++ 1 file changed, 484 insertions(+), 174 deletions(-) -- 1.7.12 -- 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 01/10] crypto: omap-aes - Remmove unnecessary pr_info noise
From: Mark A. Greer mgr...@animalcreek.com
Remove the unnecessary pr_info() calls from omap_aes_probe()
and omap_aes_mod_init().
CC: Dmitry Kasatkin dmitry.kasat...@intel.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
drivers/crypto/omap-aes.c | 4
1 file changed, 4 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index e66e8ee..481da71 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -880,8 +880,6 @@ static int omap_aes_probe(struct platform_device *pdev)
goto err_algs;
}
- pr_info(probe() done\n);
-
return 0;
err_algs:
for (j = 0; j i; j++)
@@ -938,8 +936,6 @@ static struct platform_driver omap_aes_driver = {
static int __init omap_aes_mod_init(void)
{
- pr_info(loading %s driver\n, omap-aes);
-
return platform_driver_register(omap_aes_driver);
}
--
1.7.12
--
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 10/10] crypto: omap-aes - Add CTR algorithm Support
From: Mark A. Greer mgr...@animalcreek.com
The OMAP3 and OMAP4/AM33xx versions of the AES crypto
module support the CTR algorithm in addition to ECB
and CBC that the OMAP2 version of the module supports.
So, OMAP2 and OMAP3 share a common register set but
OMAP3 supports CTR while OMAP2 doesn't. OMAP4/AM33XX
uses a different register set from OMAP2/OMAP3 and
also supports CTR.
To add this support, use the platform_data introduced
in an ealier commit to hold the list of algorithms
supported by the current module. The probe routine
will use that list to register the correct algorithms.
Note: The code being integrated is from the TI AM33xx SDK
and was written by Greg Turner gkmtur...@gmail.com and
Herman Schuurman (current email unknown) while at TI.
CC: Greg Turner gkmtur...@gmail.com
CC: Dmitry Kasatkin dmitry.kasat...@intel.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
drivers/crypto/omap-aes.c | 143 +-
1 file changed, 128 insertions(+), 15 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index bd1ad97..6aa425f 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -48,7 +48,11 @@
#define AES_REG_IV(dd, x) ((dd)-pdata-iv_ofs + ((x) * 0x04))
#define AES_REG_CTRL(dd) ((dd)-pdata-ctrl_ofs)
-#define AES_REG_CTRL_CTR_WIDTH (1 7)
+#define AES_REG_CTRL_CTR_WIDTH_MASK(3 7)
+#define AES_REG_CTRL_CTR_WIDTH_32 (0 7)
+#define AES_REG_CTRL_CTR_WIDTH_64 (1 7)
+#define AES_REG_CTRL_CTR_WIDTH_96 (2 7)
+#define AES_REG_CTRL_CTR_WIDTH_128 (3 7)
#define AES_REG_CTRL_CTR (1 6)
#define AES_REG_CTRL_CBC (1 5)
#define AES_REG_CTRL_KEY_SIZE (3 3)
@@ -76,6 +80,7 @@
#define FLAGS_ENCRYPT BIT(0)
#define FLAGS_CBC BIT(1)
#define FLAGS_GIV BIT(2)
+#define FLAGS_CTR BIT(3)
#define FLAGS_INIT BIT(4)
#define FLAGS_FAST BIT(5)
@@ -96,7 +101,16 @@ struct omap_aes_reqctx {
#define OMAP_AES_QUEUE_LENGTH 1
#define OMAP_AES_CACHE_SIZE0
+struct omap_aes_algs_info {
+ struct crypto_alg *algs_list;
+ unsigned intsize;
+ unsigned intregistered;
+};
+
struct omap_aes_pdata {
+ struct omap_aes_algs_info *algs_info;
+ unsigned intalgs_info_size;
+
void(*trigger)(struct omap_aes_dev *dd, int length);
u32 key_ofs;
@@ -208,7 +222,7 @@ static int omap_aes_write_ctrl(struct omap_aes_dev *dd)
{
unsigned int key32;
int i, err;
- u32 val, mask;
+ u32 val, mask = 0;
err = omap_aes_hw_init(dd);
if (err)
@@ -222,16 +236,20 @@ static int omap_aes_write_ctrl(struct omap_aes_dev *dd)
__le32_to_cpu(dd-ctx-key[i]));
}
- if ((dd-flags FLAGS_CBC) dd-req-info)
+ if ((dd-flags (FLAGS_CBC | FLAGS_CTR)) dd-req-info)
omap_aes_write_n(dd, AES_REG_IV(dd, 0), dd-req-info, 4);
val = FLD_VAL(((dd-ctx-keylen 3) - 1), 4, 3);
if (dd-flags FLAGS_CBC)
val |= AES_REG_CTRL_CBC;
+ if (dd-flags FLAGS_CTR) {
+ val |= AES_REG_CTRL_CTR | AES_REG_CTRL_CTR_WIDTH_32;
+ mask = AES_REG_CTRL_CTR | AES_REG_CTRL_CTR_WIDTH_MASK;
+ }
if (dd-flags FLAGS_ENCRYPT)
val |= AES_REG_CTRL_DIRECTION;
- mask = AES_REG_CTRL_CBC | AES_REG_CTRL_DIRECTION |
+ mask |= AES_REG_CTRL_CBC | AES_REG_CTRL_DIRECTION |
AES_REG_CTRL_KEY_SIZE;
omap_aes_write_mask(dd, AES_REG_CTRL(dd), val, mask);
@@ -807,6 +825,16 @@ static int omap_aes_cbc_decrypt(struct ablkcipher_request
*req)
return omap_aes_crypt(req, FLAGS_CBC);
}
+static int omap_aes_ctr_encrypt(struct ablkcipher_request *req)
+{
+ return omap_aes_crypt(req, FLAGS_ENCRYPT | FLAGS_CTR);
+}
+
+static int omap_aes_ctr_decrypt(struct ablkcipher_request *req)
+{
+ return omap_aes_crypt(req, FLAGS_CTR);
+}
+
static int omap_aes_cra_init(struct crypto_tfm *tfm)
{
pr_debug(enter\n);
@@ -823,7 +851,7 @@ static void omap_aes_cra_exit(struct crypto_tfm *tfm)
/* ** ALGS */
-static struct crypto_alg algs[] = {
+static struct crypto_alg algs_ecb_cbc[] = {
{
.cra_name = ecb(aes),
.cra_driver_name= ecb-aes-omap,
@@ -871,7 +899,43 @@ static struct crypto_alg algs[] = {
}
};
+static struct crypto_alg algs_ctr[] = {
+{
+ .cra_name = ctr(aes),
+ .cra_driver_name= ctr-aes-omap,
+ .cra_priority = 100,
+ .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER |
+ CRYPTO_ALG_KERN_DRIVER_ONLY |
+ CRYPTO_ALG_ASYNC,
+
[PATCH v2 03/10] crypto: omap-aes - Convert to use pm_runtime API
From: Mark A. Greer mgr...@animalcreek.com
Convert the omap-aes crypto driver to use the
pm_runtime API instead of the clk API.
CC: Kevin Hilman khil...@deeprootsystems.com
CC: Dmitry Kasatkin dmitry.kasat...@intel.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
drivers/crypto/omap-aes.c | 29 +++--
1 file changed, 11 insertions(+), 18 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index 33cd783..c229852 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -19,10 +19,10 @@
#include linux/init.h
#include linux/errno.h
#include linux/kernel.h
-#include linux/clk.h
#include linux/platform_device.h
#include linux/scatterlist.h
#include linux/dma-mapping.h
+#include linux/pm_runtime.h
#include linux/io.h
#include linux/crypto.h
#include linux/interrupt.h
@@ -96,7 +96,6 @@ struct omap_aes_dev {
struct list_headlist;
unsigned long phys_base;
void __iomem*io_base;
- struct clk *iclk;
struct omap_aes_ctx *ctx;
struct device *dev;
unsigned long flags;
@@ -167,7 +166,7 @@ static int omap_aes_hw_init(struct omap_aes_dev *dd)
* It may be long delays between requests.
* Device might go to off mode to save power.
*/
- clk_enable(dd-iclk);
+ pm_runtime_get_sync(dd-dev);
if (!(dd-flags FLAGS_INIT)) {
dd-flags |= FLAGS_INIT;
@@ -518,7 +517,7 @@ static void omap_aes_finish_req(struct omap_aes_dev *dd,
int err)
pr_debug(err: %d\n, err);
- clk_disable(dd-iclk);
+ pm_runtime_put_sync(dd-dev);
dd-flags = ~FLAGS_BUSY;
req-base.complete(req-base, err);
@@ -813,26 +812,21 @@ static int omap_aes_probe(struct platform_device *pdev)
else
dd-dma_in = res-start;
- /* Initializing the clock */
- dd-iclk = clk_get(dev, ick);
- if (IS_ERR(dd-iclk)) {
- dev_err(dev, clock intialization failed.\n);
- err = PTR_ERR(dd-iclk);
- goto err_res;
- }
-
dd-io_base = ioremap(dd-phys_base, SZ_4K);
if (!dd-io_base) {
dev_err(dev, can't ioremap\n);
err = -ENOMEM;
- goto err_io;
+ goto err_res;
}
- clk_enable(dd-iclk);
+ pm_runtime_enable(dev);
+ pm_runtime_get_sync(dev);
+
reg = omap_aes_read(dd, AES_REG_REV);
dev_info(dev, OMAP AES hw accel rev: %u.%u\n,
(reg AES_REG_REV_MAJOR) 4, reg AES_REG_REV_MINOR);
- clk_disable(dd-iclk);
+
+ pm_runtime_put_sync(dev);
tasklet_init(dd-done_task, omap_aes_done_task, (unsigned long)dd);
tasklet_init(dd-queue_task, omap_aes_queue_task, (unsigned long)dd);
@@ -862,8 +856,7 @@ err_dma:
tasklet_kill(dd-done_task);
tasklet_kill(dd-queue_task);
iounmap(dd-io_base);
-err_io:
- clk_put(dd-iclk);
+ pm_runtime_disable(dev);
err_res:
kfree(dd);
dd = NULL;
@@ -891,7 +884,7 @@ static int omap_aes_remove(struct platform_device *pdev)
tasklet_kill(dd-queue_task);
omap_aes_dma_cleanup(dd);
iounmap(dd-io_base);
- clk_put(dd-iclk);
+ pm_runtime_disable(dd-dev);
kfree(dd);
dd = NULL;
--
1.7.12
--
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 07/10] crypto: omap-aes - Add Device Tree Support
From: Mark A. Greer mgr...@animalcreek.com
Add Device Tree suport to the omap-aes crypto
driver. Currently, only support for OMAP2 and
OMAP3 is being added but support for OMAP4 will
be added in a subsequent patch.
CC: Dmitry Kasatkin dmitry.kasat...@intel.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
drivers/crypto/omap-aes.c | 123 --
1 file changed, 97 insertions(+), 26 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index faf522f..dfebd40 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -25,6 +25,9 @@
#include linux/dmaengine.h
#include linux/omap-dma.h
#include linux/pm_runtime.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/of_address.h
#include linux/io.h
#include linux/crypto.h
#include linux/interrupt.h
@@ -819,11 +822,97 @@ static struct crypto_alg algs[] = {
}
};
+#ifdef CONFIG_OF
+static const struct of_device_id omap_aes_of_match[] = {
+ {
+ .compatible = ti,omap2-aes,
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, omap_aes_of_match);
+
+static int omap_aes_get_res_of(struct omap_aes_dev *dd,
+ struct device *dev, struct resource *res)
+{
+ struct device_node *node = dev-of_node;
+ const struct of_device_id *match;
+ int err = 0;
+
+ match = of_match_device(of_match_ptr(omap_aes_of_match), dev);
+ if (!match) {
+ dev_err(dev, no compatible OF match\n);
+ err = -EINVAL;
+ goto err;
+ }
+
+ err = of_address_to_resource(node, 0, res);
+ if (err 0) {
+ dev_err(dev, can't translate OF node address\n);
+ err = -EINVAL;
+ goto err;
+ }
+
+ dd-dma_out = -1; /* Dummy value that's unused */
+ dd-dma_in = -1; /* Dummy value that's unused */
+
+err:
+ return err;
+}
+#else
+static const struct of_device_id omap_aes_of_match[] = {
+ {},
+};
+
+static int omap_aes_get_res_of(struct omap_aes_dev *dd,
+ struct device *dev, struct resource *res)
+{
+ return -EINVAL;
+}
+#endif
+
+static int omap_aes_get_res_pdev(struct omap_aes_dev *dd,
+ struct platform_device *pdev, struct resource *res)
+{
+ struct device *dev = pdev-dev;
+ struct resource *r;
+ int err = 0;
+
+ /* Get the base address */
+ r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!r) {
+ dev_err(dev, no MEM resource info\n);
+ err = -ENODEV;
+ goto err;
+ }
+ memcpy(res, r, sizeof(*res));
+
+ /* Get the DMA out channel */
+ r = platform_get_resource(pdev, IORESOURCE_DMA, 0);
+ if (!r) {
+ dev_err(dev, no DMA out resource info\n);
+ err = -ENODEV;
+ goto err;
+ }
+ dd-dma_out = r-start;
+
+ /* Get the DMA in channel */
+ r = platform_get_resource(pdev, IORESOURCE_DMA, 1);
+ if (!r) {
+ dev_err(dev, no DMA in resource info\n);
+ err = -ENODEV;
+ goto err;
+ }
+ dd-dma_in = r-start;
+
+err:
+ return err;
+}
+
static int omap_aes_probe(struct platform_device *pdev)
{
struct device *dev = pdev-dev;
struct omap_aes_dev *dd;
- struct resource *res;
+ struct resource res;
int err = -ENOMEM, i, j;
u32 reg;
@@ -838,35 +927,18 @@ static int omap_aes_probe(struct platform_device *pdev)
spin_lock_init(dd-lock);
crypto_init_queue(dd-queue, OMAP_AES_QUEUE_LENGTH);
- /* Get the base address */
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(dev, invalid resource type\n);
- err = -ENODEV;
+ err = (dev-of_node) ? omap_aes_get_res_of(dd, dev, res) :
+ omap_aes_get_res_pdev(dd, pdev, res);
+ if (err)
goto err_res;
- }
- dd-phys_base = res-start;
-
- /* Get the DMA */
- res = platform_get_resource(pdev, IORESOURCE_DMA, 0);
- if (!res)
- dev_info(dev, no DMA info\n);
- else
- dd-dma_out = res-start;
-
- /* Get the DMA */
- res = platform_get_resource(pdev, IORESOURCE_DMA, 1);
- if (!res)
- dev_info(dev, no DMA info\n);
- else
- dd-dma_in = res-start;
-
- dd-io_base = ioremap(dd-phys_base, SZ_4K);
+
+ dd-io_base = devm_request_and_ioremap(dev, res);
if (!dd-io_base) {
dev_err(dev, can't ioremap\n);
err = -ENOMEM;
goto err_res;
}
+ dd-phys_base = res.start;
pm_runtime_enable(dev);
pm_runtime_get_sync(dev);
@@ -904,7 +976,6 @@ err_algs:
err_dma:
tasklet_kill(dd-done_task);
tasklet_kill(dd-queue_task);
-
[PATCH v2 04/10] crypto: omap-aes - Add suspend/resume support
From: Mark A. Greer mgr...@animalcreek.com
Add suspend/resume support to the OMAP AES driver.
CC: Dmitry Kasatkin dmitry.kasat...@intel.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
drivers/crypto/omap-aes.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index c229852..3262139 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -891,12 +891,31 @@ static int omap_aes_remove(struct platform_device *pdev)
return 0;
}
+#ifdef CONFIG_PM_SLEEP
+static int omap_aes_suspend(struct device *dev)
+{
+ pm_runtime_put_sync(dev);
+ return 0;
+}
+
+static int omap_aes_resume(struct device *dev)
+{
+ pm_runtime_get_sync(dev);
+ return 0;
+}
+#endif
+
+static const struct dev_pm_ops omap_aes_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(omap_aes_suspend, omap_aes_resume)
+};
+
static struct platform_driver omap_aes_driver = {
.probe = omap_aes_probe,
.remove = omap_aes_remove,
.driver = {
.name = omap-aes,
.owner = THIS_MODULE,
+ .pm = omap_aes_pm_ops,
},
};
--
1.7.12
--
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 06/10] crypto: omap-aes - Remove usage of private DMA API
From: Mark A. Greer mgr...@animalcreek.com
Remove usage of the private OMAP DMA API.
The dmaengine API will be used instead.
CC: Russell King rmk+ker...@arm.linux.org.uk
CC: Dmitry Kasatkin dmitry.kasat...@intel.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
drivers/crypto/omap-aes.c | 133 --
1 file changed, 133 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index 14ec9e2..faf522f 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -12,8 +12,6 @@
*
*/
-#define OMAP_AES_DMA_PRIVATE
-
#define pr_fmt(fmt) %s: fmt, __func__
#include linux/err.h
@@ -115,33 +113,21 @@ struct omap_aes_dev {
struct ablkcipher_request *req;
size_t total;
struct scatterlist *in_sg;
-#ifndef OMAP_AES_DMA_PRIVATE
struct scatterlist in_sgl;
-#endif
size_t in_offset;
struct scatterlist *out_sg;
-#ifndef OMAP_AES_DMA_PRIVATE
struct scatterlist out_sgl;
-#endif
size_t out_offset;
size_t buflen;
void*buf_in;
size_t dma_size;
int dma_in;
-#ifdef OMAP_AES_DMA_PRIVATE
- int dma_lch_in;
-#else
struct dma_chan *dma_lch_in;
-#endif
dma_addr_t dma_addr_in;
void*buf_out;
int dma_out;
-#ifdef OMAP_AES_DMA_PRIVATE
- int dma_lch_out;
-#else
struct dma_chan *dma_lch_out;
-#endif
dma_addr_t dma_addr_out;
};
@@ -206,17 +192,10 @@ static int omap_aes_write_ctrl(struct omap_aes_dev *dd)
return err;
val = 0;
-#ifdef OMAP_AES_DMA_PRIVATE
- if (dd-dma_lch_out = 0)
- val |= AES_REG_MASK_DMA_OUT_EN;
- if (dd-dma_lch_in = 0)
- val |= AES_REG_MASK_DMA_IN_EN;
-#else
if (dd-dma_lch_out != NULL)
val |= AES_REG_MASK_DMA_OUT_EN;
if (dd-dma_lch_in != NULL)
val |= AES_REG_MASK_DMA_IN_EN;
-#endif
mask = AES_REG_MASK_DMA_IN_EN | AES_REG_MASK_DMA_OUT_EN;
@@ -244,22 +223,6 @@ static int omap_aes_write_ctrl(struct omap_aes_dev *dd)
omap_aes_write_mask(dd, AES_REG_CTRL, val, mask);
-#ifdef OMAP_AES_DMA_PRIVATE
- /* IN */
- omap_set_dma_dest_params(dd-dma_lch_in, 0, OMAP_DMA_AMODE_CONSTANT,
-dd-phys_base + AES_REG_DATA, 0, 4);
-
- omap_set_dma_dest_burst_mode(dd-dma_lch_in, OMAP_DMA_DATA_BURST_4);
- omap_set_dma_src_burst_mode(dd-dma_lch_in, OMAP_DMA_DATA_BURST_4);
-
- /* OUT */
- omap_set_dma_src_params(dd-dma_lch_out, 0, OMAP_DMA_AMODE_CONSTANT,
- dd-phys_base + AES_REG_DATA, 0, 4);
-
- omap_set_dma_src_burst_mode(dd-dma_lch_out, OMAP_DMA_DATA_BURST_4);
- omap_set_dma_dest_burst_mode(dd-dma_lch_out, OMAP_DMA_DATA_BURST_4);
-#endif
-
return 0;
}
@@ -284,23 +247,6 @@ static struct omap_aes_dev *omap_aes_find_dev(struct
omap_aes_ctx *ctx)
return dd;
}
-#ifdef OMAP_AES_DMA_PRIVATE
-static void omap_aes_dma_callback(int lch, u16 ch_status, void *data)
-{
- struct omap_aes_dev *dd = data;
-
- if (ch_status != OMAP_DMA_BLOCK_IRQ) {
- pr_err(omap-aes DMA error status: 0x%hx\n, ch_status);
- dd-err = -EIO;
- dd-flags = ~FLAGS_INIT; /* request to re-initialize */
- } else if (lch == dd-dma_lch_in) {
- return;
- }
-
- /* dma_lch_out - completed */
- tasklet_schedule(dd-done_task);
-}
-#else
static void omap_aes_dma_out_callback(void *data)
{
struct omap_aes_dev *dd = data;
@@ -308,22 +254,14 @@ static void omap_aes_dma_out_callback(void *data)
/* dma_lch_out - completed */
tasklet_schedule(dd-done_task);
}
-#endif
static int omap_aes_dma_init(struct omap_aes_dev *dd)
{
int err = -ENOMEM;
-#ifndef OMAP_AES_DMA_PRIVATE
dma_cap_mask_t mask;
-#endif
-#ifdef OMAP_AES_DMA_PRIVATE
- dd-dma_lch_out = -1;
- dd-dma_lch_in = -1;
-#else
dd-dma_lch_out = NULL;
dd-dma_lch_in = NULL;
-#endif
dd-buf_in = (void *)__get_free_pages(GFP_KERNEL, OMAP_AES_CACHE_SIZE);
dd-buf_out = (void *)__get_free_pages(GFP_KERNEL, OMAP_AES_CACHE_SIZE);
@@ -352,20 +290,6 @@ static int omap_aes_dma_init(struct omap_aes_dev *dd)
goto err_map_out;
}
-#ifdef OMAP_AES_DMA_PRIVATE
- err = omap_request_dma(dd-dma_in, omap-aes-rx,
- omap_aes_dma_callback, dd, dd-dma_lch_in);
- if (err) {
- dev_err(dd-dev, Unable to request DMA channel\n);
- goto err_dma_in;
- }
- err
[PATCH v2 09/10] crypto: omap-aes - Add OMAP4/AM33XX AES Support
From: Mark A. Greer mgr...@animalcreek.com
Add support for the OMAP4 version of the AES module
that is present on OMAP4 and AM33xx SoCs.
The modules have several differences including register
offsets and how DMA is triggered. To handle these
differences, a platform_data structure is defined and
contains routine pointers, register offsets, and bit
offsets within registers. OMAP2/OMAP3-specific routines
are suffixed with '_omap2' and OMAP4/AM33xx routines are
suffixed with '_omap4'.
Note: The code being integrated is from the TI AM33xx SDK
and was written by Greg Turner gkmtur...@gmail.com and
Herman Schuurman (current email unknown) while at TI.
CC: Greg Turner gkmtur...@gmail.com
CC: Dmitry Kasatkin dmitry.kasat...@intel.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
drivers/crypto/omap-aes.c | 158 --
1 file changed, 125 insertions(+), 33 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index d34aa5d..bd1ad97 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -5,6 +5,7 @@
*
* Copyright (c) 2010 Nokia Corporation
* Author: Dmitry Kasatkin dmitry.kasat...@nokia.com
+ * Copyright (c) 2011 Texas Instruments Incorporated
*
* 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
@@ -42,10 +43,11 @@
#define FLD_MASK(start, end) (((1 ((start) - (end) + 1)) - 1) (end))
#define FLD_VAL(val, start, end) (((val) (end)) FLD_MASK(start, end))
-#define AES_REG_KEY(x) (0x1C - ((x ^ 0x01) * 0x04))
-#define AES_REG_IV(x) (0x20 + ((x) * 0x04))
+#define AES_REG_KEY(dd, x) ((dd)-pdata-key_ofs - \
+ ((x ^ 0x01) * 0x04))
+#define AES_REG_IV(dd, x) ((dd)-pdata-iv_ofs + ((x) * 0x04))
-#define AES_REG_CTRL 0x30
+#define AES_REG_CTRL(dd) ((dd)-pdata-ctrl_ofs)
#define AES_REG_CTRL_CTR_WIDTH (1 7)
#define AES_REG_CTRL_CTR (1 6)
#define AES_REG_CTRL_CBC (1 5)
@@ -54,14 +56,11 @@
#define AES_REG_CTRL_INPUT_READY (1 1)
#define AES_REG_CTRL_OUTPUT_READY (1 0)
-#define AES_REG_DATA 0x34
-#define AES_REG_DATA_N(x) (0x34 + ((x) * 0x04))
+#define AES_REG_DATA_N(dd, x) ((dd)-pdata-data_ofs + ((x) * 0x04))
-#define AES_REG_REV0x44
-#define AES_REG_REV_MAJOR 0xF0
-#define AES_REG_REV_MINOR 0x0F
+#define AES_REG_REV(dd)((dd)-pdata-rev_ofs)
-#define AES_REG_MASK 0x48
+#define AES_REG_MASK(dd) ((dd)-pdata-mask_ofs)
#define AES_REG_MASK_SIDLE (1 6)
#define AES_REG_MASK_START (1 5)
#define AES_REG_MASK_DMA_OUT_EN(1 3)
@@ -69,8 +68,7 @@
#define AES_REG_MASK_SOFTRESET (1 1)
#define AES_REG_AUTOIDLE (1 0)
-#define AES_REG_SYSSTATUS 0x4C
-#define AES_REG_SYSSTATUS_RESETDONE(1 0)
+#define AES_REG_LENGTH_N(x)(0x54 + ((x) * 0x04))
#define DEFAULT_TIMEOUT(5*HZ)
@@ -98,6 +96,26 @@ struct omap_aes_reqctx {
#define OMAP_AES_QUEUE_LENGTH 1
#define OMAP_AES_CACHE_SIZE0
+struct omap_aes_pdata {
+ void(*trigger)(struct omap_aes_dev *dd, int length);
+
+ u32 key_ofs;
+ u32 iv_ofs;
+ u32 ctrl_ofs;
+ u32 data_ofs;
+ u32 rev_ofs;
+ u32 mask_ofs;
+
+ u32 dma_enable_in;
+ u32 dma_enable_out;
+ u32 dma_start;
+
+ u32 major_mask;
+ u32 major_shift;
+ u32 minor_mask;
+ u32 minor_shift;
+};
+
struct omap_aes_dev {
struct list_headlist;
unsigned long phys_base;
@@ -132,6 +150,8 @@ struct omap_aes_dev {
int dma_out;
struct dma_chan *dma_lch_out;
dma_addr_t dma_addr_out;
+
+ const struct omap_aes_pdata *pdata;
};
/* keep registered devices data here */
@@ -194,26 +214,16 @@ static int omap_aes_write_ctrl(struct omap_aes_dev *dd)
if (err)
return err;
- val = 0;
- if (dd-dma_lch_out != NULL)
- val |= AES_REG_MASK_DMA_OUT_EN;
- if (dd-dma_lch_in != NULL)
- val |= AES_REG_MASK_DMA_IN_EN;
-
- mask = AES_REG_MASK_DMA_IN_EN | AES_REG_MASK_DMA_OUT_EN;
-
- omap_aes_write_mask(dd, AES_REG_MASK, val, mask);
-
key32 = dd-ctx-keylen / sizeof(u32);
/* it seems a key should always be set even if it has not changed */
for (i = 0; i key32; i++) {
- omap_aes_write(dd, AES_REG_KEY(i),
+
[PATCH v2 05/10] crypto: omap-aes - Add code to use dmaengine API
From: Mark A. Greer mgr...@animalcreek.com
Add code to use the new dmaengine API alongside
the existing DMA code that uses the private
OMAP DMA API. The API to use is chosen by
defining or undefining 'OMAP_AES_DMA_PRIVATE'.
CC: Russell King rmk+ker...@arm.linux.org.uk
CC: Dmitry Kasatkin dmitry.kasat...@intel.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
drivers/crypto/omap-aes.c | 184 +-
1 file changed, 183 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index 3262139..14ec9e2 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -12,6 +12,8 @@
*
*/
+#define OMAP_AES_DMA_PRIVATE
+
#define pr_fmt(fmt) %s: fmt, __func__
#include linux/err.h
@@ -22,6 +24,8 @@
#include linux/platform_device.h
#include linux/scatterlist.h
#include linux/dma-mapping.h
+#include linux/dmaengine.h
+#include linux/omap-dma.h
#include linux/pm_runtime.h
#include linux/io.h
#include linux/crypto.h
@@ -29,7 +33,8 @@
#include crypto/scatterwalk.h
#include crypto/aes.h
-#include linux/omap-dma.h
+#define DST_MAXBURST 4
+#define DMA_MIN(DST_MAXBURST * sizeof(u32))
/* OMAP TRM gives bitfields as start:end, where start is the higher bit
number. For example 7:0 */
@@ -110,19 +115,33 @@ struct omap_aes_dev {
struct ablkcipher_request *req;
size_t total;
struct scatterlist *in_sg;
+#ifndef OMAP_AES_DMA_PRIVATE
+ struct scatterlist in_sgl;
+#endif
size_t in_offset;
struct scatterlist *out_sg;
+#ifndef OMAP_AES_DMA_PRIVATE
+ struct scatterlist out_sgl;
+#endif
size_t out_offset;
size_t buflen;
void*buf_in;
size_t dma_size;
int dma_in;
+#ifdef OMAP_AES_DMA_PRIVATE
int dma_lch_in;
+#else
+ struct dma_chan *dma_lch_in;
+#endif
dma_addr_t dma_addr_in;
void*buf_out;
int dma_out;
+#ifdef OMAP_AES_DMA_PRIVATE
int dma_lch_out;
+#else
+ struct dma_chan *dma_lch_out;
+#endif
dma_addr_t dma_addr_out;
};
@@ -187,10 +206,17 @@ static int omap_aes_write_ctrl(struct omap_aes_dev *dd)
return err;
val = 0;
+#ifdef OMAP_AES_DMA_PRIVATE
if (dd-dma_lch_out = 0)
val |= AES_REG_MASK_DMA_OUT_EN;
if (dd-dma_lch_in = 0)
val |= AES_REG_MASK_DMA_IN_EN;
+#else
+ if (dd-dma_lch_out != NULL)
+ val |= AES_REG_MASK_DMA_OUT_EN;
+ if (dd-dma_lch_in != NULL)
+ val |= AES_REG_MASK_DMA_IN_EN;
+#endif
mask = AES_REG_MASK_DMA_IN_EN | AES_REG_MASK_DMA_OUT_EN;
@@ -218,6 +244,7 @@ static int omap_aes_write_ctrl(struct omap_aes_dev *dd)
omap_aes_write_mask(dd, AES_REG_CTRL, val, mask);
+#ifdef OMAP_AES_DMA_PRIVATE
/* IN */
omap_set_dma_dest_params(dd-dma_lch_in, 0, OMAP_DMA_AMODE_CONSTANT,
dd-phys_base + AES_REG_DATA, 0, 4);
@@ -231,6 +258,7 @@ static int omap_aes_write_ctrl(struct omap_aes_dev *dd)
omap_set_dma_src_burst_mode(dd-dma_lch_out, OMAP_DMA_DATA_BURST_4);
omap_set_dma_dest_burst_mode(dd-dma_lch_out, OMAP_DMA_DATA_BURST_4);
+#endif
return 0;
}
@@ -256,6 +284,7 @@ static struct omap_aes_dev *omap_aes_find_dev(struct
omap_aes_ctx *ctx)
return dd;
}
+#ifdef OMAP_AES_DMA_PRIVATE
static void omap_aes_dma_callback(int lch, u16 ch_status, void *data)
{
struct omap_aes_dev *dd = data;
@@ -271,13 +300,30 @@ static void omap_aes_dma_callback(int lch, u16 ch_status,
void *data)
/* dma_lch_out - completed */
tasklet_schedule(dd-done_task);
}
+#else
+static void omap_aes_dma_out_callback(void *data)
+{
+ struct omap_aes_dev *dd = data;
+
+ /* dma_lch_out - completed */
+ tasklet_schedule(dd-done_task);
+}
+#endif
static int omap_aes_dma_init(struct omap_aes_dev *dd)
{
int err = -ENOMEM;
+#ifndef OMAP_AES_DMA_PRIVATE
+ dma_cap_mask_t mask;
+#endif
+#ifdef OMAP_AES_DMA_PRIVATE
dd-dma_lch_out = -1;
dd-dma_lch_in = -1;
+#else
+ dd-dma_lch_out = NULL;
+ dd-dma_lch_in = NULL;
+#endif
dd-buf_in = (void *)__get_free_pages(GFP_KERNEL, OMAP_AES_CACHE_SIZE);
dd-buf_out = (void *)__get_free_pages(GFP_KERNEL, OMAP_AES_CACHE_SIZE);
@@ -306,6 +352,7 @@ static int omap_aes_dma_init(struct omap_aes_dev *dd)
goto err_map_out;
}
+#ifdef OMAP_AES_DMA_PRIVATE
err = omap_request_dma(dd-dma_in, omap-aes-rx,
omap_aes_dma_callback,
[PATCH v2 08/10] crypto: omap-aes - Convert to dma_request_slave_channel_compat()
From: Mark A. Greer mgr...@animalcreek.com
Use the dma_request_slave_channel_compat() call instead of
the dma_request_channel() call to request a DMA channel.
This allows the omap-aes driver use different DMA engines.
CC: Dmitry Kasatkin dmitry.kasat...@intel.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
drivers/crypto/omap-aes.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index dfebd40..d34aa5d 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -296,15 +296,19 @@ static int omap_aes_dma_init(struct omap_aes_dev *dd)
dma_cap_zero(mask);
dma_cap_set(DMA_SLAVE, mask);
- dd-dma_lch_in = dma_request_channel(mask, omap_dma_filter_fn,
-dd-dma_in);
+ dd-dma_lch_in = dma_request_slave_channel_compat(mask,
+ omap_dma_filter_fn,
+ dd-dma_in,
+ dd-dev, rx);
if (!dd-dma_lch_in) {
dev_err(dd-dev, Unable to request in DMA channel\n);
goto err_dma_in;
}
- dd-dma_lch_out = dma_request_channel(mask, omap_dma_filter_fn,
-dd-dma_out);
+ dd-dma_lch_out = dma_request_slave_channel_compat(mask,
+ omap_dma_filter_fn,
+ dd-dma_out,
+ dd-dev, tx);
if (!dd-dma_lch_out) {
dev_err(dd-dev, Unable to request out DMA channel\n);
goto err_dma_out;
--
1.7.12
--
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 07/10] crypto: omap-aes - Add Device Tree Support
On Fri, Dec 28, 2012 at 02:06:02AM -0800, Russ Dill wrote:
On Fri, Dec 21, 2012 at 10:04 AM, Mark A. Greer mgr...@animalcreek.com
wrote:
From: Mark A. Greer mgr...@animalcreek.com
Add Device Tree suport to the omap-aes crypto
driver. Currently, only support for OMAP2 and
OMAP3 is being added but support for OMAP4 will
be added in a subsequent patch.
CC: Dmitry Kasatkin dmitry.kasat...@intel.com
Signed-off-by: Mark A. Greer mgr...@animalcreek.com
---
drivers/crypto/omap-aes.c | 119
--
1 file changed, 93 insertions(+), 26 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index faf522f..68bf22d 100644
--- a/drivers/crypto/omap-aes.c
+++ b/drivers/crypto/omap-aes.c
@@ -25,6 +25,9 @@
#include linux/dmaengine.h
#include linux/omap-dma.h
#include linux/pm_runtime.h
+#include linux/of.h
+#include linux/of_device.h
+#include linux/of_address.h
#include linux/io.h
#include linux/crypto.h
#include linux/interrupt.h
@@ -819,11 +822,93 @@ static struct crypto_alg algs[] = {
}
};
+#ifdef CONFIG_OF
+static const struct of_device_id omap_aes_of_match[] = {
+ {
+ .compatible = ti,omap2-aes,
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, omap_aes_of_match);
I think you mean for the above section to be outside of the '#ifdef
CONFIG_OF' block.
+static int omap_aes_get_res_of(struct omap_aes_dev *dd,
+ struct device *dev, struct resource *res)
+{
+ struct device_node *node = dev-of_node;
+ const struct of_device_id *match;
+ int err = 0;
+
+ match = of_match_device(of_match_ptr(omap_aes_of_match), dev);
+ if (!match) {
+ dev_err(dev, no compatible OF match\n);
+ err = -EINVAL;
+ goto err;
+ }
+
+ err = of_address_to_resource(node, 0, res);
+ if (err 0) {
+ dev_err(dev, can't translate OF node address\n);
+ err = -EINVAL;
+ goto err;
+ }
+
+ dd-dma_out = -1; /* Dummy value that's unused */
+ dd-dma_in = -1; /* Dummy value that's unused */
+
+err:
+ return err;
+}
+#else
+static int omap_aes_get_res_dev(struct omap_aes_dev *dd,
+ struct device *dev, struct resource *res)
+{
+ return -EINVAL;
+}
And I think you mean this one to be omap_aes_get_res_of
Your comments should be addressed in v2 of this series,
http://www.spinics.net/lists/linux-omap/msg84629.html
Mark
--
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP AM3517/05: hwmod data: block WFI when EMAC active
On Sun, 30 Dec 2012, Paul Walmsley wrote:
However, for some reason, we don't have an EMAC hwmod -- probably some
bug in the data -- so set the flag on the MDIO hwmod data instead.
Mark and I discussed this in private E-mail. Looks like I managed to
confuse AM33xx and AM3517 :-( Here's the updated patch.
- Paul
From: Paul Walmsley p...@pwsan.com
Date: Sun, 30 Dec 2012 10:36:36 -0700
Subject: [PATCH] ARM: OMAP AM3517/05: hwmod data: block WFI when EMAC active
According to Mark Greer, on OMAP AM3517/3505 chips, the EMAC is unable
to wake the ARM up from WFI:
http://www.spinics.net/lists/arm-kernel/msg174734.html
Further troubleshooting was unable to narrow the problem down. So we
don't have much choice other than to block WFI when the EMAC is active
with the HWMOD_BLOCK_WFI flag.
Based on Mark's original patch. We're removing the omap_device-based
pm_lats code, so a different approach was needed.
This second version contains some corrections thanks to Mark's review.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Mark A. Greer mgr...@animalcreek.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 8bb2628..7af28b7 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3493,7 +3493,13 @@ static struct omap_hwmod am35xx_emac_hwmod = {
.name = davinci_emac,
.mpu_irqs = am35xx_emac_mpu_irqs,
.class = am35xx_emac_class,
- .flags = HWMOD_NO_IDLEST,
+ /*
+* According to Mark Greer, the MPU will not return from WFI
+* when the EMAC signals an interrupt. We're missing an EMAC
+* hwmod for some reason, so add the flag to the MDIO instead.
+* http://www.spinics.net/lists/arm-kernel/msg174734.html
+*/
+ .flags = (HWMOD_NO_IDLEST | HWMOD_BLOCK_WFI),
};
/* l3_core - davinci emac interface */
--
1.7.10.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 00/15] OMAP SHAM AES Crypto Updates
On Sun, Dec 23, 2012 at 08:40:43AM +, Paul Walmsley wrote:
Hi Mark,
Hi Paul.
On Fri, 21 Dec 2012, Mark A. Greer wrote:
From: Mark A. Greer mgr...@animalcreek.com
[This series supersedes the hwmod related patches sent in the
crypto: omap-sham updates and crypto: omap-aes updates
series a few weeks ago.]
This series adds hwmod support for the OMAP SHAM and AES
modules on OMAP2, OMAP3, and OMAP4/AM33XX SoCs. It also
adds device tree info for those modules.
Thanks for working on this, this will get us much closer to being able to
convert the hwmod code into an OMAP bus. I haven't looked closely at
these patches yet, but a few comments/questions:
- The patch series causes AM3517/3505 to crash. I'd guess this is due to
the SHAM/AES modules being initialized on those chips, but they probably
don't exist there. Can you change the initialization for those on OMAP3
to only take place on OMAP34xx/36xx GP? I guess you'd need to create new
lists for those in the hwmod init.
All am35xx GPs have the SHAM and AES modules except some very old ones.
I've been told that there should be very few of the old ones around
(I don't know how to differentiate them). We're likely safe since the
SHAM AES modules are not enabled in omap2plus_defconfig so nobody
should be enabling them on an am35xx unless they know that they have
the modules. Do you agree?
The issue that you're likely running into is that 'CK_AM35XX' needs to be
added for aes2_ick sha12_ick in cclock3xxx_data.c. The following
patch should fix it (applies to my submitted/crypto/hwmod branch):
diff --git a/arch/arm/mach-omap2/cclock3xxx_data.c
b/arch/arm/mach-omap2/cclock3xxx_data.c
index 582b055..aa5bdf6 100644
--- a/arch/arm/mach-omap2/cclock3xxx_data.c
+++ b/arch/arm/mach-omap2/cclock3xxx_data.c
@@ -3332,10 +3332,10 @@ static struct omap_clk omap3xxx_clks[] = {
CLK(omap_hsmmc.2, ick, mmchs3_ick,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, mmchs3_ick, mmchs3_ick,CK_3430ES2PLUS |
CK_AM35XX | CK_36XX),
CLK(NULL, icr_ick, icr_ick, CK_34XX | CK_36XX),
- CLK(omap-aes, ick, aes2_ick, CK_34XX | CK_36XX),
- CLK(NULL, aes2_ick, aes2_ick, CK_34XX | CK_36XX),
- CLK(omap-sham,ick, sha12_ick, CK_34XX | CK_36XX),
- CLK(NULL, sha12_ick,sha12_ick, CK_34XX | CK_36XX),
+ CLK(omap-aes, ick, aes2_ick, CK_34XX | CK_AM35XX |
CK_36XX),
+ CLK(NULL, aes2_ick, aes2_ick, CK_34XX | CK_AM35XX |
CK_36XX),
+ CLK(omap-sham,ick, sha12_ick, CK_34XX | CK_AM35XX |
CK_36XX),
+ CLK(NULL, sha12_ick,sha12_ick, CK_34XX | CK_AM35XX |
CK_36XX),
CLK(NULL, des2_ick, des2_ick, CK_34XX | CK_36XX),
CLK(omap_hsmmc.1, ick, mmchs2_ick,CK_3XXX),
CLK(omap_hsmmc.0, ick, mmchs1_ick,CK_3XXX),
Please let me know if this patch works for you and, if it does, I'll respin
my patches to add those changes.
Thanks,
Mark
--
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP AM3517/05: hwmod data: block WFI when EMAC active
On Tue, Jan 08, 2013 at 07:21:16PM +, Paul Walmsley wrote:
On Sun, 30 Dec 2012, Paul Walmsley wrote:
Hi Paul.
However, for some reason, we don't have an EMAC hwmod -- probably some
bug in the data -- so set the flag on the MDIO hwmod data instead.
Mark and I discussed this in private E-mail. Looks like I managed to
confuse AM33xx and AM3517 :-( Here's the updated patch.
- Paul
From: Paul Walmsley p...@pwsan.com
Date: Sun, 30 Dec 2012 10:36:36 -0700
Subject: [PATCH] ARM: OMAP AM3517/05: hwmod data: block WFI when EMAC active
According to Mark Greer, on OMAP AM3517/3505 chips, the EMAC is unable
to wake the ARM up from WFI:
http://www.spinics.net/lists/arm-kernel/msg174734.html
Further troubleshooting was unable to narrow the problem down. So we
don't have much choice other than to block WFI when the EMAC is active
with the HWMOD_BLOCK_WFI flag.
Based on Mark's original patch. We're removing the omap_device-based
pm_lats code, so a different approach was needed.
This second version contains some corrections thanks to Mark's review.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Mark A. Greer mgr...@animalcreek.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index 8bb2628..7af28b7 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -3493,7 +3493,13 @@ static struct omap_hwmod am35xx_emac_hwmod = {
.name = davinci_emac,
.mpu_irqs = am35xx_emac_mpu_irqs,
.class = am35xx_emac_class,
- .flags = HWMOD_NO_IDLEST,
+ /*
+ * According to Mark Greer, the MPU will not return from WFI
+ * when the EMAC signals an interrupt. We're missing an EMAC
+ * hwmod for some reason, so add the flag to the MDIO instead.
+ * http://www.spinics.net/lists/arm-kernel/msg174734.html
+ */
+ .flags = (HWMOD_NO_IDLEST | HWMOD_BLOCK_WFI),
};
Sorry to nag but I think the comment needs to be updated to remove the
sentence about the missing EMAC hwmod.
Mark
--
--
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 5/5] kfifo: log based kfifo API
Dmitry Torokhov dmitry.torok...@gmail.com wrote:
Hi Yuanhan,
On Tue, Jan 08, 2013 at 10:57:53PM +0800, Yuanhan Liu wrote:
The current kfifo API take the kfifo size as input, while it rounds
_down_ the size to power of 2 at __kfifo_alloc. This may introduce
potential issue.
Take the code at drivers/hid/hid-logitech-dj.c as example:
if (kfifo_alloc(djrcv_dev-notif_fifo,
DJ_MAX_NUMBER_NOTIFICATIONS * sizeof(struct
dj_report),
GFP_KERNEL)) {
Where, DJ_MAX_NUMBER_NOTIFICATIONS is 8, and sizeo of(struct
dj_report)
is 15.
Which means it wants to allocate a kfifo buffer which can store 8
dj_report entries at once. The expected kfifo buffer size would be
8 * 15 = 120 then. While, in the end, __kfifo_alloc will turn the
size to rounddown_power_of_2(120) = 64, and then allocate a buf
with 64 bytes, which I don't think this is the original author want.
With the new log API, we can do like following:
int kfifo_size_order = order_base_2(DJ_MAX_NUMBER_NOTIFICATIONS *
sizeof(struct dj_report));
if (kfifo_alloc(djrcv_dev-notif_fifo, kfifo_size_order,
GFP_KERNEL)) {
This make sure we will allocate enough kfifo buffer for holding
DJ_MAX_NUMBER_NOTIFICATIONS dj_report entries.
Why don't you simply change __kfifo_alloc to round the allocation up
instead of down?
Thanks.
--
Dmitry
--
To unsubscribe from this list: send the line unsubscribe linux-media
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Dmitry,
I agree. I don't see the benefit in pushing up the change to a kfifo internal
decision/problem to many different places in the kernel.
Regards,
Andy
--
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
Help wanted with USB and OMAP3 off_mode
Hi,
I'm trying to get off_mode working reliably on my gta04 mobile phone.
My current stumbling block is USB. The Option GSM module is attached via
USB (there is a separate transceiver chip attached to port 1 which is placed
in OMAP_EHCI_PORT_MODE_PHY).
After a suspend/resume cycle with off_mode enabled the GSM module disappears.
i.e. 'lsusb' doesn't see it any more and the various ttyHSxx devices don't
exist.
Without off mode, the modem always appears after resume.
I discovered that the registers set by:
drivers/mfd/omap-usb-host.c
are not maintained across as suspend/resume so I added the following patch
(which I can make a formal submission of if it looks right to others), but
that didn't help (or didn't help enough).
If I
echo 1 /sys/kernel/debug/pm_debug/usbhost_pwrdm/suspend
thus keeping just the USBHOST power domain out of off_mode, the GSM module
doesn't disappear. So it seems that some context in the usbhost domain is
not being save and restored.
This is as far as I can get. Can someone suggest where I should look to find
out what is not being saved/restored properly, and how to go about saving and
restoring?
Thanks in advance,
NeilBrown
diff --git a/drivers/mfd/omap-usb-host.c b/drivers/mfd/omap-usb-host.c
index 23cec57..522405e 100644
--- a/drivers/mfd/omap-usb-host.c
+++ b/drivers/mfd/omap-usb-host.c
@@ -100,6 +100,10 @@ struct usbhs_hcd_omap {
void __iomem*uhh_base;
+ struct {
+ unsignedhostconfig;
+ } context;
+
struct usbhs_omap_platform_data platdata;
u32 usbhs_rev;
@@ -300,6 +304,10 @@ static int usbhs_runtime_resume(struct device *dev)
clk_enable(omap-utmi_p1_fck);
clk_enable(omap-utmi_p2_fck);
+ usbhs_write(omap-uhh_base,
+ OMAP_UHH_HOSTCONFIG,
+ omap-context.hostconfig);
+
spin_unlock_irqrestore(omap-lock, flags);
return 0;
@@ -319,6 +327,8 @@ static int usbhs_runtime_suspend(struct device *dev)
}
spin_lock_irqsave(omap-lock, flags);
+ omap-context.hostconfig = usbhs_read(omap-uhh_base,
+ OMAP_UHH_HOSTCONFIG);
if (is_ehci_tll_mode(pdata-port_mode[0]))
clk_disable(omap-usbhost_p1_fck);
signature.asc
Description: PGP signature
Re: Build failure with DMA_OMAP=m and a caller built-in
On Monday 07 January 2013, Russell King - ARM Linux wrote: The problem we have is that the way peripheral devices are connected to their DMA engines can involve additional complexity, which if not handled correctly results in some platforms being crippled by the API. I think Vinod was working on something, however I've not heard anything on that for a while now. How we avoid this problem outside of OMAP is that the DMA filter function gets passed from platform code, and we only ever allow the DMA engine driver to be configured into the kernel (iow, non-modular). This means that the DMA users never directly reference the DMA engine driver itself. However, as OMAP headed down the DT path, many drivers no longer make use of platform data, which makes that approach impractical. Hmm, it seems the generic DT binding for dmaengine missed the merge window again, Vinod's pull request came a bit too late for this[1]. Anyway, once the binding and code from Jon Hunter is there, and the omap-dma converted over to use it, the problem should be gone, unless you see any other issues with it. Drivers no longer need to reference a filter function directly, since the dma channel can get described completely in the DT. Arnd [1] http://lkml.org/lkml/2012/12/21/466 -- 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 5/5] kfifo: log based kfifo API
On Tue, Jan 08, 2013 at 10:16:46AM -0800, Dmitry Torokhov wrote:
Hi Yuanhan,
On Tue, Jan 08, 2013 at 10:57:53PM +0800, Yuanhan Liu wrote:
The current kfifo API take the kfifo size as input, while it rounds
_down_ the size to power of 2 at __kfifo_alloc. This may introduce
potential issue.
Take the code at drivers/hid/hid-logitech-dj.c as example:
if (kfifo_alloc(djrcv_dev-notif_fifo,
DJ_MAX_NUMBER_NOTIFICATIONS * sizeof(struct
dj_report),
GFP_KERNEL)) {
Where, DJ_MAX_NUMBER_NOTIFICATIONS is 8, and sizeo of(struct dj_report)
is 15.
Which means it wants to allocate a kfifo buffer which can store 8
dj_report entries at once. The expected kfifo buffer size would be
8 * 15 = 120 then. While, in the end, __kfifo_alloc will turn the
size to rounddown_power_of_2(120) = 64, and then allocate a buf
with 64 bytes, which I don't think this is the original author want.
With the new log API, we can do like following:
int kfifo_size_order = order_base_2(DJ_MAX_NUMBER_NOTIFICATIONS *
sizeof(struct dj_report));
if (kfifo_alloc(djrcv_dev-notif_fifo, kfifo_size_order, GFP_KERNEL)) {
This make sure we will allocate enough kfifo buffer for holding
DJ_MAX_NUMBER_NOTIFICATIONS dj_report entries.
Why don't you simply change __kfifo_alloc to round the allocation up
instead of down?
Hi Dmitry,
Yes, it would be neat and that was my first reaction as well. I then
sent out a patch, but it was NACKed by Stefani(the original kfifo
author). Here is the link:
https://lkml.org/lkml/2012/10/26/144
Then Stefani proposed to change the API to take log of size as input to
root fix this kind of issues. And here it is.
Thanks.
--yliu
--
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
[RFC 0/4] TI LCDC DRM driver
Updated version of DRM driver for TI LCD Controller. Since the initial version of the patch, which only supported TFP410 DVI output, I've added an output driver for LCD panels (for example, LCD3 or LCD7 cape for the beagle-bone), and initial support for HDMI output via NXP TDA19988 HDMI encoder (via i2c encoder-slave output driver). At this point, I think the basic lcdc drm driver plus TFP410 DVI output (first patch) is in reasonable shape (barring potential rename, if lcdc is too generic of a name... but I was not feeling creative enough yet to pick a new name). The second patch, adding LCD panel support, still needs backlight support. And the DT bindings for panel parameters should probably be made more generic. But I guess someone should have some opinions on that so I figured it would be good to send as an RFC in it's current form and hear other's opinions. The remaining two patches, adding support for HDMI output via NXP TDA998x i2c encoder are fairly preliminary, but basically working (for some definitions of working). At this point, there is only basic DVI output support. Audio, HDCP, etc, can come later. Rob Clark (4): RFC: drm/lcdc: add TI LCD Controller DRM driver (v2) RFC: drm/lcdc: add support for LCD panels (v2) RFC: drm/i2c: nxp-tda998x RFC: drm/lcdc: add encoder slave drivers/gpu/drm/Kconfig| 2 + drivers/gpu/drm/Makefile | 1 + drivers/gpu/drm/i2c/Makefile | 3 + drivers/gpu/drm/i2c/tda998x_drv.c | 907 + drivers/gpu/drm/lcdc/Kconfig | 24 + drivers/gpu/drm/lcdc/Makefile | 10 + drivers/gpu/drm/lcdc/lcdc_crtc.c | 598 drivers/gpu/drm/lcdc/lcdc_drv.c| 608 + drivers/gpu/drm/lcdc/lcdc_drv.h| 164 +++ drivers/gpu/drm/lcdc/lcdc_panel.c | 458 +++ drivers/gpu/drm/lcdc/lcdc_panel.h | 26 ++ drivers/gpu/drm/lcdc/lcdc_regs.h | 154 +++ drivers/gpu/drm/lcdc/lcdc_slave.c | 384 drivers/gpu/drm/lcdc/lcdc_slave.h | 26 ++ drivers/gpu/drm/lcdc/lcdc_tfp410.c | 425 + drivers/gpu/drm/lcdc/lcdc_tfp410.h | 26 ++ 16 files changed, 3816 insertions(+) create mode 100644 drivers/gpu/drm/i2c/tda998x_drv.c create mode 100644 drivers/gpu/drm/lcdc/Kconfig create mode 100644 drivers/gpu/drm/lcdc/Makefile create mode 100644 drivers/gpu/drm/lcdc/lcdc_crtc.c create mode 100644 drivers/gpu/drm/lcdc/lcdc_drv.c create mode 100644 drivers/gpu/drm/lcdc/lcdc_drv.h create mode 100644 drivers/gpu/drm/lcdc/lcdc_panel.c create mode 100644 drivers/gpu/drm/lcdc/lcdc_panel.h create mode 100644 drivers/gpu/drm/lcdc/lcdc_regs.h create mode 100644 drivers/gpu/drm/lcdc/lcdc_slave.c create mode 100644 drivers/gpu/drm/lcdc/lcdc_slave.h create mode 100644 drivers/gpu/drm/lcdc/lcdc_tfp410.c create mode 100644 drivers/gpu/drm/lcdc/lcdc_tfp410.h -- 1.8.0.2 -- 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/4] RFC: drm/lcdc: add support for LCD panels (v2)
Add an output panel driver for LCD panels. Tested with LCD3 cape on
beaglebone.
TODO: need some way to control the appropriate backlight device
TODO: probably want to make the DT bindings more generic for panel-info
v1: original
v2: s/of_find_node_by_name()/of_get_child_by_name()/ from Pantelis
Antoniou
Signed-off-by: Rob Clark robdcl...@gmail.com
---
drivers/gpu/drm/lcdc/Kconfig | 2 +
drivers/gpu/drm/lcdc/Makefile | 1 +
drivers/gpu/drm/lcdc/lcdc_drv.c | 3 +
drivers/gpu/drm/lcdc/lcdc_panel.c | 458 ++
drivers/gpu/drm/lcdc/lcdc_panel.h | 26 +++
5 files changed, 490 insertions(+)
create mode 100644 drivers/gpu/drm/lcdc/lcdc_panel.c
create mode 100644 drivers/gpu/drm/lcdc/lcdc_panel.h
diff --git a/drivers/gpu/drm/lcdc/Kconfig b/drivers/gpu/drm/lcdc/Kconfig
index 58806d4..7806184 100644
--- a/drivers/gpu/drm/lcdc/Kconfig
+++ b/drivers/gpu/drm/lcdc/Kconfig
@@ -4,6 +4,8 @@ config DRM_LCDC
select DRM_KMS_HELPER
select DRM_KMS_CMA_HELPER
select DRM_GEM_CMA_HELPER
+ select DISPLAY_TIMING
+ select OF_DISPLAY_TIMINGS
help
Choose this option if you have an TI SoC with LCDC display
controller, for example AM33xx in beagle-bone, DA8xx, or
diff --git a/drivers/gpu/drm/lcdc/Makefile b/drivers/gpu/drm/lcdc/Makefile
index db32161..27d19ce 100644
--- a/drivers/gpu/drm/lcdc/Makefile
+++ b/drivers/gpu/drm/lcdc/Makefile
@@ -3,6 +3,7 @@ ccflags-y := -Iinclude/drm -Werror
lcdc-y := \
lcdc_crtc.o \
lcdc_tfp410.o \
+ lcdc_panel.o \
lcdc_drv.o
obj-$(CONFIG_DRM_LCDC) += lcdc.o
diff --git a/drivers/gpu/drm/lcdc/lcdc_drv.c b/drivers/gpu/drm/lcdc/lcdc_drv.c
index 5e6d218..ee892cb 100644
--- a/drivers/gpu/drm/lcdc/lcdc_drv.c
+++ b/drivers/gpu/drm/lcdc/lcdc_drv.c
@@ -20,6 +20,7 @@
#include lcdc_drv.h
#include lcdc_regs.h
#include lcdc_tfp410.h
+#include lcdc_panel.h
#include drm_fb_helper.h
@@ -584,6 +585,7 @@ static int __init lcdc_drm_init(void)
{
DBG(init);
lcdc_tfp410_init();
+ lcdc_panel_init();
return platform_driver_register(lcdc_platform_driver);
}
@@ -591,6 +593,7 @@ static void __exit lcdc_drm_fini(void)
{
DBG(fini);
lcdc_tfp410_fini();
+ lcdc_panel_fini();
platform_driver_unregister(lcdc_platform_driver);
}
diff --git a/drivers/gpu/drm/lcdc/lcdc_panel.c
b/drivers/gpu/drm/lcdc/lcdc_panel.c
new file mode 100644
index 000..037e2d2
--- /dev/null
+++ b/drivers/gpu/drm/lcdc/lcdc_panel.c
@@ -0,0 +1,458 @@
+/*
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Rob Clark robdcl...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/pinctrl/pinmux.h
+#include linux/pinctrl/consumer.h
+#include linux/of_display_timings.h
+
+#include lcdc_drv.h
+
+struct panel_module {
+ struct lcdc_module base;
+ struct lcdc_panel_info *info;
+ struct display_timings *timings;
+};
+#define to_panel_module(x) container_of(x, struct panel_module, base)
+
+
+/*
+ * Encoder:
+ */
+
+struct panel_encoder {
+ struct drm_encoder base;
+ struct panel_module *mod;
+};
+#define to_panel_encoder(x) container_of(x, struct panel_encoder, base)
+
+
+static void panel_encoder_destroy(struct drm_encoder *encoder)
+{
+ struct panel_encoder *panel_encoder = to_panel_encoder(encoder);
+ drm_encoder_cleanup(encoder);
+ kfree(panel_encoder);
+}
+
+static void panel_encoder_dpms(struct drm_encoder *encoder, int mode)
+{
+}
+
+static bool panel_encoder_mode_fixup(struct drm_encoder *encoder,
+ const struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
+{
+ /* nothing needed */
+ return true;
+}
+
+static void panel_encoder_prepare(struct drm_encoder *encoder)
+{
+ struct panel_encoder *panel_encoder = to_panel_encoder(encoder);
+ panel_encoder_dpms(encoder, DRM_MODE_DPMS_OFF);
+ lcdc_crtc_set_panel_info(encoder-crtc, panel_encoder-mod-info);
+}
+
+static void panel_encoder_commit(struct drm_encoder *encoder)
+{
+ panel_encoder_dpms(encoder, DRM_MODE_DPMS_ON);
+}
+
+static void panel_encoder_mode_set(struct drm_encoder *encoder,
+ struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode)
+{
+ /* nothing needed */
+}
+
+static const struct drm_encoder_funcs panel_encoder_funcs = {
+
[PATCH 3/4] RFC: drm/i2c: nxp-tda998x
Driver for the NXP TDA998X i2c hdmi encoder slave.
Signed-off-by: Rob Clark robdcl...@gmail.com
---
drivers/gpu/drm/i2c/Makefile | 3 +
drivers/gpu/drm/i2c/tda998x_drv.c | 907 ++
2 files changed, 910 insertions(+)
create mode 100644 drivers/gpu/drm/i2c/tda998x_drv.c
diff --git a/drivers/gpu/drm/i2c/Makefile b/drivers/gpu/drm/i2c/Makefile
index 9286256..43aa33b 100644
--- a/drivers/gpu/drm/i2c/Makefile
+++ b/drivers/gpu/drm/i2c/Makefile
@@ -5,3 +5,6 @@ obj-$(CONFIG_DRM_I2C_CH7006) += ch7006.o
sil164-y := sil164_drv.o
obj-$(CONFIG_DRM_I2C_SIL164) += sil164.o
+
+tda998x-y := tda998x_drv.o
+obj-$(CONFIG_DRM_I2C_NXP_TDA998X) += tda998x.o
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
new file mode 100644
index 000..47f8fd2
--- /dev/null
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -0,0 +1,907 @@
+/*
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Rob Clark robdcl...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+
+
+#include linux/module.h
+
+#include drm/drmP.h
+#include drm/drm_crtc_helper.h
+#include drm/drm_encoder_slave.h
+#include drm/drm_edid.h
+
+
+#define DBG(fmt, ...) DRM_DEBUG(fmt\n, ##__VA_ARGS__)
+
+struct tda998x_priv {
+ struct i2c_client *cec;
+ uint16_t rev;
+ uint8_t current_page;
+ int dpms;
+};
+
+#define to_tda998x_priv(x) ((struct tda998x_priv
*)to_encoder_slave(x)-slave_priv)
+
+/* The TDA9988 series of devices use a paged register scheme.. to simplify
+ * things we encode the page # in upper bits of the register #. To read/
+ * write a given register, we need to make sure CURPAGE register is set
+ * appropriately. Which implies reads/writes are not atomic. Fun!
+ */
+
+#define REG(page, addr) (((page) 8) | (addr))
+#define REG2ADDR(reg) ((reg) 0xff)
+#define REG2PAGE(reg) (((reg) 8) 0xff)
+
+#define REG_CURPAGE 0xff/* write */
+
+
+/* Page 00h: General Control */
+#define REG_VERSION_LSB REG(0x00, 0x00) /* read */
+#define REG_MAIN_CNTRL0 REG(0x00, 0x01) /* read/write */
+# define MAIN_CNTRL0_SR (1 0)
+# define MAIN_CNTRL0_DECS (1 1)
+# define MAIN_CNTRL0_DEHS (1 2)
+# define MAIN_CNTRL0_CECS (1 3)
+# define MAIN_CNTRL0_CEHS (1 4)
+# define MAIN_CNTRL0_SCALER (1 7)
+#define REG_VERSION_MSB REG(0x00, 0x02) /* read */
+#define REG_SOFTRESET REG(0x00, 0x0a) /* write */
+# define SOFTRESET_AUDIO (1 0)
+# define SOFTRESET_I2C_MASTER (1 1)
+#define REG_DDC_DISABLE REG(0x00, 0x0b) /* read/write */
+#define REG_CCLK_ON REG(0x00, 0x0c) /* read/write */
+#define REG_I2C_MASTERREG(0x00, 0x0d) /* read/write */
+# define I2C_MASTER_DIS_MM(1 0)
+# define I2C_MASTER_DIS_FILT (1 1)
+# define I2C_MASTER_APP_STRT_LAT (1 2)
+#define REG_INT_FLAGS_0 REG(0x00, 0x0f) /* read/write */
+#define REG_INT_FLAGS_1 REG(0x00, 0x10) /* read/write */
+#define REG_INT_FLAGS_2 REG(0x00, 0x11) /* read/write */
+# define INT_FLAGS_2_EDID_BLK_RD (1 1)
+#define REG_ENA_VP_0 REG(0x00, 0x18) /* read/write */
+#define REG_ENA_VP_1 REG(0x00, 0x19) /* read/write */
+#define REG_ENA_VP_2 REG(0x00, 0x1a) /* read/write */
+#define REG_ENA_APREG(0x00, 0x1e) /* read/write */
+#define REG_VIP_CNTRL_0 REG(0x00, 0x20) /* write */
+# define VIP_CNTRL_0_MIRR_A (1 7)
+# define VIP_CNTRL_0_SWAP_A(x)(((x) 7) 4)
+# define VIP_CNTRL_0_MIRR_B (1 3)
+# define VIP_CNTRL_0_SWAP_B(x)(((x) 7) 0)
+#define REG_VIP_CNTRL_1 REG(0x00, 0x21) /* write */
+# define VIP_CNTRL_1_MIRR_C (1 7)
+# define VIP_CNTRL_1_SWAP_C(x)(((x) 7) 4)
+# define VIP_CNTRL_1_MIRR_D (1 3)
+# define VIP_CNTRL_1_SWAP_D(x)(((x) 7) 0)
+#define REG_VIP_CNTRL_2 REG(0x00, 0x22) /* write */
+# define VIP_CNTRL_2_MIRR_E (1 7)
+# define VIP_CNTRL_2_SWAP_E(x)(((x) 7) 4)
+# define VIP_CNTRL_2_MIRR_F (1 3)
+# define VIP_CNTRL_2_SWAP_F(x)(((x) 7) 0)
+#define REG_VIP_CNTRL_3 REG(0x00, 0x23) /* write */
+# define VIP_CNTRL_3_X_TGL(1 0)
+# define VIP_CNTRL_3_H_TGL(1 1)
+# define VIP_CNTRL_3_V_TGL(1 2)
+# define
[PATCH 4/4] RFC: drm/lcdc: add encoder slave
Add output panel driver for i2c encoder slaves.
Signed-off-by: Rob Clark robdcl...@gmail.com
---
drivers/gpu/drm/lcdc/Kconfig | 12 ++
drivers/gpu/drm/lcdc/Makefile | 1 +
drivers/gpu/drm/lcdc/lcdc_drv.c | 5 +-
drivers/gpu/drm/lcdc/lcdc_slave.c | 384 ++
drivers/gpu/drm/lcdc/lcdc_slave.h | 26 +++
5 files changed, 427 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/lcdc/lcdc_slave.c
create mode 100644 drivers/gpu/drm/lcdc/lcdc_slave.h
diff --git a/drivers/gpu/drm/lcdc/Kconfig b/drivers/gpu/drm/lcdc/Kconfig
index 7806184..e88809c 100644
--- a/drivers/gpu/drm/lcdc/Kconfig
+++ b/drivers/gpu/drm/lcdc/Kconfig
@@ -10,3 +10,15 @@ config DRM_LCDC
Choose this option if you have an TI SoC with LCDC display
controller, for example AM33xx in beagle-bone, DA8xx, or
OMAP-L1xx. This driver replaces the FB_DA8XX fbdev driver.
+
+menu I2C encoder or helper chips
+ depends on DRM DRM_KMS_HELPER I2C
+
+config DRM_I2C_NXP_TDA998X
+ tristate NXP Semiconductors TDA998X HDMI encoder
+ default m if DRM_LCDC
+ help
+ Support for NXP Semiconductors TDA998X HDMI encoders.
+
+endmenu
+
diff --git a/drivers/gpu/drm/lcdc/Makefile b/drivers/gpu/drm/lcdc/Makefile
index 27d19ce..337e22f 100644
--- a/drivers/gpu/drm/lcdc/Makefile
+++ b/drivers/gpu/drm/lcdc/Makefile
@@ -4,6 +4,7 @@ lcdc-y := \
lcdc_crtc.o \
lcdc_tfp410.o \
lcdc_panel.o \
+ lcdc_slave.o \
lcdc_drv.o
obj-$(CONFIG_DRM_LCDC) += lcdc.o
diff --git a/drivers/gpu/drm/lcdc/lcdc_drv.c b/drivers/gpu/drm/lcdc/lcdc_drv.c
index ee892cb..643664f 100644
--- a/drivers/gpu/drm/lcdc/lcdc_drv.c
+++ b/drivers/gpu/drm/lcdc/lcdc_drv.c
@@ -21,6 +21,7 @@
#include lcdc_regs.h
#include lcdc_tfp410.h
#include lcdc_panel.h
+#include lcdc_slave.h
#include drm_fb_helper.h
@@ -586,6 +587,7 @@ static int __init lcdc_drm_init(void)
DBG(init);
lcdc_tfp410_init();
lcdc_panel_init();
+ lcdc_slave_init();
return platform_driver_register(lcdc_platform_driver);
}
@@ -594,10 +596,11 @@ static void __exit lcdc_drm_fini(void)
DBG(fini);
lcdc_tfp410_fini();
lcdc_panel_fini();
+ lcdc_slave_fini();
platform_driver_unregister(lcdc_platform_driver);
}
-module_init(lcdc_drm_init);
+late_initcall(lcdc_drm_init);
module_exit(lcdc_drm_fini);
MODULE_AUTHOR(Rob Clark robdcl...@gmail.com);
diff --git a/drivers/gpu/drm/lcdc/lcdc_slave.c
b/drivers/gpu/drm/lcdc/lcdc_slave.c
new file mode 100644
index 000..8534c81
--- /dev/null
+++ b/drivers/gpu/drm/lcdc/lcdc_slave.c
@@ -0,0 +1,384 @@
+/*
+ * Copyright (C) 2012 Texas Instruments
+ * Author: Rob Clark robdcl...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/i2c.h
+#include linux/of_i2c.h
+#include linux/pinctrl/pinmux.h
+#include linux/pinctrl/consumer.h
+#include drm/drm_encoder_slave.h
+
+#include lcdc_drv.h
+
+struct slave_module {
+ struct lcdc_module base;
+ struct i2c_adapter *i2c;
+};
+#define to_slave_module(x) container_of(x, struct slave_module, base)
+
+// TODO maybe this should come from DT?
+static const struct lcdc_panel_info slave_info = {
+ .min_bpp= 16,
+ .max_bpp= 16,
+ .ac_bias= 255,
+ .ac_bias_intrpt = 0,
+ .dma_burst_sz = 16,
+ .bpp= 16,
+ .fdd= 0x80,
+ .tft_alt_mode = 0,
+ .stn_565_mode = 0,
+ .mono_8bit_mode = 0,
+ .invert_line_clock = 1,
+ .invert_frm_clock = 1,
+ .sync_edge = 0,
+ .sync_ctrl = 1,
+ .raster_order = 0,
+};
+
+
+/*
+ * Encoder:
+ */
+
+struct slave_encoder {
+ struct drm_encoder_slave base;
+ struct slave_module *mod;
+};
+#define to_slave_encoder(x) container_of(to_encoder_slave(x), struct
slave_encoder, base)
+
+static inline struct drm_encoder_slave_funcs *
+get_slave_funcs(struct drm_encoder *enc)
+{
+ return to_encoder_slave(enc)-slave_funcs;
+}
+
+static void slave_encoder_destroy(struct drm_encoder *encoder)
+{
+ struct slave_encoder *slave_encoder =
RE: [RFC v2 01/18] mailbox: OMAP2+: Add support for AM33XX
On Tue, Jan 08, 2013 at 19:23:44, Shilimkar, Santosh wrote:
On Monday 31 December 2012 06:36 PM, Vaibhav Bedia wrote:
Mailbox IP on AM33XX is the same as that present in OMAP4.
The single instance of Mailbox IP on AM33XX contains
8 sub-modules and facilitates communication between MPU,
PRUs and WKUP_M3.
PRUS?
Programmable Real Time Units. Will clarify in next version
The first mailbox sub-module is assigned for communication
between MPU and WKUP-M3.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
Cc: Russ Dill russ.d...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
v1-v2:
Address the comment on operator usage from Russ Dill
drivers/mailbox/mailbox-omap2.c | 35 ++-
1 files changed, 34 insertions(+), 1 deletions(-)
diff --git a/drivers/mailbox/mailbox-omap2.c
b/drivers/mailbox/mailbox-omap2.c
index 7c26bed..6d61159 100644
--- a/drivers/mailbox/mailbox-omap2.c
+++ b/drivers/mailbox/mailbox-omap2.c
@@ -151,7 +151,7 @@ static void omap2_mbox_disable_irq(struct mailbox *mbox,
struct omap_mbox2_priv *p = mbox-priv;
u32 bit = (irq == IRQ_TX) ? p-notfull_bit : p-newmsg_bit;
- if (!cpu_is_omap44xx())
+ if (!cpu_is_omap44xx() !soc_is_am33xx())
bit = mbox_read_reg(p-irqdisable) ~bit;
mbox_write_reg(bit, p-irqdisable);
@@ -352,6 +352,32 @@ struct mailbox mbox_2_info = {
struct mailbox *omap4_mboxes[] = { mbox_1_info, mbox_2_info, NULL };
#endif
+#if defined(CONFIG_SOC_AM33XX)
+static struct omap_mbox2_priv omap2_mbox_wkup_m3_priv = {
+ .tx_fifo = {
+ .msg= MAILBOX_MESSAGE(0),
+ .fifo_stat = MAILBOX_FIFOSTATUS(0),
+ .msg_stat = MAILBOX_MSGSTATUS(0),
+ },
+ .rx_fifo = {
+ .msg= MAILBOX_MESSAGE(1),
+ .msg_stat = MAILBOX_MSGSTATUS(1),
+ },
+ .irqenable = OMAP4_MAILBOX_IRQENABLE(3),
+ .irqstatus = OMAP4_MAILBOX_IRQSTATUS(3),
+ .irqdisable = OMAP4_MAILBOX_IRQENABLE_CLR(3),
+ .notfull_bit= MAILBOX_IRQ_NOTFULL(0),
+ .newmsg_bit = MAILBOX_IRQ_NEWMSG(0),
+};
+
+struct mailbox mbox_wkup_m3_info = {
+ .name = wkup_m3,
+ .ops= omap2_mbox_ops,
+ .priv = omap2_mbox_wkup_m3_priv,
+};
+struct mailbox *am33xx_mboxes[] = { mbox_wkup_m3_info, NULL };
+#endif
+
static int __devinit omap2_mbox_probe(struct platform_device *pdev)
{
struct resource *mem;
@@ -386,6 +412,13 @@ static int __devinit omap2_mbox_probe(struct
platform_device *pdev)
list[0]-irq = list[1]-irq = platform_get_irq(pdev, 0);
}
#endif
+#if defined(CONFIG_SOC_AM33XX)
ifdef in middle of the code. I know you are just
following what is already there.
+ else if (soc_is_am33xx()) {
+ list = am33xx_mboxes;
+
UN-necessary extra line here.
Will remove
+ list[0]-irq = platform_get_irq(pdev, 0);
+ }
+#endif
Hopefully mailbox clean-up will kill that #ifdeffery.
Apart from those comments, patch looks fine to me.
Thanks,
Vaibhav
--
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 v2 02/18] mailbox: Add an API for flushing the FIFO
On Tue, Jan 08, 2013 at 19:26:51, Shilimkar, Santosh wrote:
On Monday 31 December 2012 06:36 PM, Vaibhav Bedia wrote:
On AM33XX, the mailbox module between the MPU and the
WKUP-M3 co-processor facilitates a one-way communication.
MPU uses the assigned mailbox sub-module to issue the
interrupt to the WKUP-M3 co-processor which then goes
and reads the the IPC data from registers in the control
module.
WKUP-M3 is in the L4_WKUP and does not have any access to
the mailbox module. Due to this limitation, the MPU is
completely responsible for FIFO maintenance and interrupt
generation. MPU needs to ensure that the FIFO does not
overflow by reading back the assigned mailbox sub-module.
This patch adds an API in the mailbox code which the MPU
can use to empty the FIFO by issuing a readback command.
Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com
Cc: Santosh Shilimkar santosh.shilim...@ti.com
---
Note: This patch which will be slightly reworked once the mailbox
driver changes are finalized.
Can you expand a bit please ?
There could be some changes in the structure names.
drivers/mailbox/mailbox-omap2.c | 19 +++
drivers/mailbox/mailbox.c | 36
drivers/mailbox/mailbox.h |3 +++
include/linux/mailbox.h |1 +
4 files changed, 59 insertions(+), 0 deletions(-)
diff --git a/drivers/mailbox/mailbox-omap2.c
b/drivers/mailbox/mailbox-omap2.c
index 6d61159..c732be1 100644
--- a/drivers/mailbox/mailbox-omap2.c
+++ b/drivers/mailbox/mailbox-omap2.c
@@ -125,6 +125,23 @@ static int omap2_mbox_fifo_full(struct mailbox *mbox)
return mbox_read_reg(fifo-fifo_stat);
}
+static int omap2_mbox_fifo_needs_flush(struct mailbox *mbox)
+{
+ struct omap_mbox2_priv *p = mbox-priv;
+ struct omap_mbox2_fifo *fifo = p-tx_fifo;
+
+ return mbox_read_reg(fifo-msg_stat);
+}
+
+static void omap2_mbox_fifo_readback(struct mailbox *mbox,
+ struct mailbox_msg *msg)
+{
+ struct omap_mbox2_priv *p = mbox-priv;
+ struct omap_mbox2_fifo *fifo = p-tx_fifo;
+
+ msg-header = mbox_read_reg(fifo-msg);
+}
+
static int ompa2_mbox_poll_for_space(struct mailbox *mbox)
{
if (omap2_mbox_fifo_full(mbox))
@@ -221,6 +238,8 @@ static struct mailbox_ops omap2_mbox_ops = {
.read = omap2_mbox_fifo_read,
.write = omap2_mbox_fifo_write,
.empty = omap2_mbox_fifo_empty,
+ .fifo_needs_flush = omap2_mbox_fifo_needs_flush,
+ .fifo_readback = omap2_mbox_fifo_readback,
.poll_for_space = ompa2_mbox_poll_for_space,
.enable_irq = omap2_mbox_enable_irq,
.disable_irq= omap2_mbox_disable_irq,
diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
index 2f50226..92c9f68 100644
--- a/drivers/mailbox/mailbox.c
+++ b/drivers/mailbox/mailbox.c
@@ -57,6 +57,15 @@ static inline int mbox_empty(struct mailbox *mbox)
{
return mbox-ops-empty(mbox);
}
+static inline int mbox_fifo_needs_flush(struct mailbox *mbox)
+{
+ return mbox-ops-fifo_needs_flush(mbox);
+}
+static inline void mbox_fifo_readback(struct mailbox *mbox,
+ struct mailbox_msg *msg)
+{
+ mbox-ops-fifo_readback(mbox, msg);
+}
/* Mailbox IRQ handle functions */
static inline void ack_mbox_irq(struct mailbox *mbox, mailbox_irq_t irq)
@@ -110,6 +119,33 @@ out:
}
EXPORT_SYMBOL(mailbox_msg_send);
+/*
s/*/**
Will do.
+ * Flush the Rx FIFO by reading back the messages
+ * Since the normal expectation is that the Rx will do the
+ * reading, add a debug message to indicate if we really flush
+ *
+ * Returns the no. of messages read back
+ */
Just look at the kernel doc style for above
Rest looks fine.
Ok.
Thanks,
Vaibhav
--
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 v2 03/18] memory: emif: Move EMIF related header file to include/linux/
On Tue, Jan 08, 2013 at 19:34:41, Shilimkar, Santosh wrote:
[...]
drivers/memory/emif.c |2 +-
drivers/memory/emif.h | 589
---
include/linux/ti_emif.h | 589
+++
You are just moving the file. So git mv file1 flie2; and the git
format-patch -C
on committed patch should just generate few lines of patch.
Ok. Didn't know about this.
+/* DDR_PHY_CTRL_1 - EMIF4D5 */
+#define DLL_HALF_DELAY_SHIFT_4D5 21
+#define DLL_HALF_DELAY_MASK_4D5(1 21)
+#define READ_LATENCY_SHIFT_4D5 0
+#define READ_LATENCY_MASK_4D5 (0x1f 0)
+
+/* DDR_PHY_CTRL_1_SHDW */
+#define DDR_PHY_CTRL_1_SHDW_SHIFT 5
+#define DDR_PHY_CTRL_1_SHDW_MASK (0x7ff 5)
+#define READ_LATENCY_SHDW_SHIFT0
+#define READ_LATENCY_SHDW_MASK (0x1f 0)
+
+#ifndef __ASSEMBLY__
+/*
+ * Structure containing shadow of important registers in EMIF
+ * The calculation function fills in this structure to be later used for
+ * initialisation and DVFS
+ */
+struct emif_regs {
Are you using above struct. If not we can leave it in same place and
just move the register defines.
No, the struct is not used. I'll leave it here in the next version.
Regards,
Vaibhav
--
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 v2 05/18] ARM: OMAP2+: AM33XX: CM/PRM: Use __ASSEMBLER__ macros in header files
On Tue, Jan 08, 2013 at 20:31:44, Shilimkar, Santosh wrote: [...] +#endif /* ASSEMBLER */ + Drop that extra line. Ok. #endif diff --git a/arch/arm/mach-omap2/prm33xx.h b/arch/arm/mach-omap2/prm33xx.h index 3f25c56..2f2eaa0 100644 --- a/arch/arm/mach-omap2/prm33xx.h +++ b/arch/arm/mach-omap2/prm33xx.h @@ -117,6 +117,7 @@ #define AM33XX_PM_CEFUSE_PWRSTST_OFFSET 0x0004 #define AM33XX_PM_CEFUSE_PWRSTST AM33XX_PRM_REGADDR(AM33XX_PRM_CEFUSE_MOD, 0x0004) +#ifndef __ASSEMBLER__ extern u32 am33xx_prm_read_reg(s16 inst, u16 idx); extern void am33xx_prm_write_reg(u32 val, s16 inst, u16 idx); extern u32 am33xx_prm_rmw_reg_bits(u32 mask, u32 bits, s16 inst, s16 idx); @@ -126,4 +127,6 @@ extern int am33xx_prm_is_hardreset_asserted(u8 shift, s16 inst, extern int am33xx_prm_assert_hardreset(u8 shift, s16 inst, u16 rstctrl_offs); extern int am33xx_prm_deassert_hardreset(u8 shift, s16 inst, u16 rstctrl_offs, u16 rstst_offs); +#endif /* ASSEMBLER */ + ditto Ok. Otherwise looks fine. Acked-by: Santosh Shilimkar santosh.shilim...@ti.com Thanks, Vaibhav -- 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 v2 13/18] ARM: OMAP2+: AM33XX: timer: Interchance clkevt and clksrc timers
On Tue, Jan 08, 2013 at 20:47:28, Shilimkar, Santosh wrote: On Monday 31 December 2012 06:37 PM, Vaibhav Bedia wrote: AM33XX has two timers (DTIMER0/1) in the WKUP domain. On GP devices the source of DMTIMER0 is fixed to an inaccurate internal 32k RC oscillator and this makes the DMTIMER0 practically either as a clocksource or as clockevent. Currently the timer instance in WKUP domain is used as the clockevent and the timer in non-WKUP domain as the clocksource. DMTIMER1 in WKUP domain can keep running in suspend from a 32K clock fed from external OSC and can serve as the persistent clock for the kernel. To enable this, interchange the timers used as clocksource and clockevent for AM33XX. For now a new DT property has been added to allow the timer code to select the timer with the right property. It has been pointed out by Santosh Shilimkar and Kevin Hilman that such a change will result in soc-idle never being achieved on AM33XX. There are other reasons why soc-idle does not look feasible on AM33XX so for now we go ahead with the interchange of the the timers. If at a later point of time we do come up with an approach which makes soc-idle possible on AM33XX, this can be revisited. Can you please explain other reasons as well for clarity ? I guess from h/w perspective it boils down to lack of HW-AUTO and IO-Daisy chaining on AM33xx [1]. Since there's no 32ksynctimer, do we also need to register DMTIMER1 as the persistent clock on AM33xx? This can only be done from DMTIMER1 which is currently serving as the clockevent. Regards, Vaibhav [1] http://marc.info/?l=linux-arm-kernelm=135238055717206w=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: [RFC v2 00/18] ARM: OMAP2+: AM33XX: Add suspend-resume support
Hi Santosh, On Tue, Jan 08, 2013 at 21:01:51, Shilimkar, Santosh wrote: Vaibhav, On Monday 31 December 2012 06:36 PM, Vaibhav Bedia wrote: Hi, This is the second version of the patch series for adding suspend-resume support for AM33XX. Based on the feedback received on the previous patch series [1] almost all the patches have undergone a bit a rework. The 1st two patches depend on the changes for mailbox code migration from arch/arm/*-omap*/ to drivers/mailbox/ [2]. The patch series also depends on recent changes to the OMAP PM framework by Paul Walmsley. I found it easiest to apply the AM33XX suspend-resume patches on top of Paul's TEST_pwrdm_post_fpwrst_devel_a_3.9 branch + the patches @ [2]. With these dependencies met, the PM code uses the firmware interface and expects the userspace to load the WKUP_M3 binary before the suspend-resume functionality is made available. The binary file (and the source-code for WKUP_M3) can be obtained from the 'next' branch at [3]. The WKUP_M3 binary can either be loaded post bootup via the sysfs entry './sys/devices/ocp.2/wkup_m3.4/firmware' or it can be included in the kernel image as part of the build process. DDR3 specific changes have been skipped for now since mainline U-Boot exhibited stability issues on all the DDR3 based AM335x boards that i could lay my hands on. I have done basic testing along with power measurments on the different power rails on the AM335x EVM. PER domain transition on the BeagleBone fails if the CPSW driver is included in the kernel and is yet to be root caused. Along with this issue more extensive testing on other OMAP platforms is also pending right now. For more details on the AM335x suspend-resume support please refer to the changelog in the different patches. I still haven't reviewed patch 15, 16 and 18 which adds suspend support. Will do that in coming days since they need a bit a closer look. But as mentioned in some of the patches, you need to split this series since except 15, 16 and 18 which adds suspend support, rest of the patches are - data file fixes - timer suspend/resume update - mailbox support, control module update. Would be good to split the series to help the reviews. Sure. I'll split it up like you mentioned. Since all these changes are needed for a working suspend-resume I kept it in a single series to reduce dependencies and also to help set an initial context for the AM33xx PM changes. Regards, Vaibhav -- 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 v2 17/18] ARM: OMAP2+: AM33XX: Select Mailbox when PM is enabled
On Tue, Jan 08, 2013 at 20:52:37, Shilimkar, Santosh wrote: On Monday 31 December 2012 06:37 PM, Vaibhav Bedia wrote: PM services on AM33XX depend on mailbox for communication with WKUP-M3 core so ensure that the right config options are selected. Thanks to Kevin Hilman khil...@deeprootsystems.com for the suggestion on updating the Kconfig and not just the omap2plus_defconfig which was done in the previous version of the AM33XX suspend-resume support. Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com Cc: Tony Lingren t...@atomide.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@deeprootsystems.com --- Unrelated to series. You can post this patch separately. Ok. I kept it in this series so that it does not look to be some random patch. Regards, Vaibhav -- 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 v2 14/18] ARM: OMAP2+: AM33XX: control: Add some control module registers and APIs
On Tue, Jan 08, 2013 at 20:51:08, Shilimkar, Santosh wrote: On Monday 31 December 2012 06:37 PM, Vaibhav Bedia wrote: Add minimal APIs for writing to the IPC and the M3_TXEV registers in the Control module. These will be used in a subsequent patch which adds suspend-resume support for AM33XX. Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com Cc: Tony Lingren t...@atomide.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Vaibhav Hiremath hvaib...@ti.com --- On Control module, we are trying to move driver/module specific code to respective drivers. Can you not add below code to ipc related driver component. If not, then patch as such is fine with me. I had it in the pm33xx.c in the previous version. Kevin had asked me to move it to control.c. Should I revert move it back there? Regards, Vaibhav -- 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 v2 07/18] ARM: OMAP2+: AM33XX: hwmod: Update TPTC0 hwmod with the right flags
On Tue, Jan 08, 2013 at 20:35:39, Shilimkar, Santosh wrote: On Monday 31 December 2012 06:37 PM, Vaibhav Bedia wrote: TPTC0 needs to be idled and put to standby under SW control. Add the appropriate flags in the TPTC0 hwmod entry. Can you please expand TPTC0 in chane log. Third Party Transfer Controller. It's part of the DMA IP. Will add it in the changelog. Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Vaibhav Hiremath hvaib...@ti.com --- Patch is fine otherwise. 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
Re: [RFC v2 14/18] ARM: OMAP2+: AM33XX: control: Add some control module registers and APIs
On Wednesday 09 January 2013 11:08 AM, Bedia, Vaibhav wrote: On Tue, Jan 08, 2013 at 20:51:08, Shilimkar, Santosh wrote: On Monday 31 December 2012 06:37 PM, Vaibhav Bedia wrote: Add minimal APIs for writing to the IPC and the M3_TXEV registers in the Control module. These will be used in a subsequent patch which adds suspend-resume support for AM33XX. Signed-off-by: Vaibhav Bedia vaibhav.be...@ti.com Cc: Tony Lingren t...@atomide.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Benoit Cousson b-cous...@ti.com Cc: Paul Walmsley p...@pwsan.com Cc: Kevin Hilman khil...@deeprootsystems.com Cc: Vaibhav Hiremath hvaib...@ti.com --- On Control module, we are trying to move driver/module specific code to respective drivers. Can you not add below code to ipc related driver component. If not, then patch as such is fine with me. I had it in the pm33xx.c in the previous version. Kevin had asked me to move it to control.c. Should I revert move it back there? pm33xx.c is not the right place. I was hoping to move to some driver. If that is not possible then leave it in control module. 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
