[PATCH] usb: dwc3: fix the error returned with usb3_phy failure
When there is an error with the usb3_phy probe or absence, the error returned
is erroneously for usb2_phy.
Signed-off-by: Ruchika Kharwar ruch...@ti.com
---
drivers/usb/dwc3/core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index c35d49d..358375e 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -450,7 +450,7 @@ static int dwc3_probe(struct platform_device *pdev)
}
if (IS_ERR(dwc-usb3_phy)) {
- ret = PTR_ERR(dwc-usb2_phy);
+ ret = PTR_ERR(dwc-usb3_phy);
/*
* if -ENXIO is returned, it means PHY layer wasn't
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] Query on Audio DMA using DMAEngine
On 07/03/2013 08:12 PM, Mark Brown wrote: On Wed, Jul 03, 2013 at 12:55:36PM -0500, Joel Fernandes wrote: When would it not be possible to cope with a large period size? Are there any guidelines on what to consider when fixing a period size? This is an application issue not a driver issue. An application that wants low latency may need high resolution information about what exactly the hardware is doing. To get low-latency, the best thing from userspace is to mmap the audio buffer, and monitor the position of the DMA transfers. If the driver reports the DMA position accurately, you can get latencies of only a few samples. I must admit that I know next to nothing about how ALSA works in userspace, but that's how DirectSound works, for example. And from what I've seen, this is also possible with ALSA. Even without that - I tried with small periods of only 40 samples, this invariably fails on the current driver, with or without the ping-ping. Using the cyclic DMA I had no problem using such small periods. Mike. -- 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: [alsa-devel] Query on Audio DMA using DMAEngine
On 07/03/2013 07:55 PM, Joel Fernandes wrote: Copying some more lists are we're also discussing the DMA controller in the SoCs. Thanks. On 07/03/2013 04:43 AM, Mark Brown wrote: On Wed, Jul 03, 2013 at 11:09:22AM +0200, Lars-Peter Clausen wrote: On 07/02/2013 02:13 PM, Mark Brown wrote: This sort of cyclic thing tends to be best, ideally you don't need interrupts at all (other than a timer). Yes, this is usually how it is done. But I'm wondering maybe the EDMA controller only has a small total amount of slots available. Well, you don't need particularly many slots so long as you can cope with a large period size. Hi Mark, When would it not be possible to cope with a large period size? Are there any guidelines on what to consider when fixing a period size? I see tegra and aux1x go upto .period_bytes_min = 1024 About slots, following are no.of slots on some SoCs with EDMA: am1808 - 96 slots available + 32 taken up for channel but can be reused with some changes. am335x - 172 slots available + 64 taken up for channels On a slightly different note, about buffer_bytes_max, is there any drawback to setting it to a smaller value? Currently 128K is about what is used on davinci-pcm. My idea is to map to do the direct mapping to IRAM if the IRAM transfers are really what are preventing the under runs, but 128K will be too much for the buffer as we don't have that much IRAM infact it is just the boundary on am33xx (128K) In any case, using the IRAM directly might have some use, because you don't have to compete for the DDRRAM with other devices. But I never understood what the ping-ping via IRAM was supposed to accomplish, I don't see why McASP - IRAM - DDRRAM (or the other way around) would be better than just McASP - DDRRAM. Especially since the McASP has a built-in 256 byte FIFO buffer on both channels. In all my measurements, using the IRAM ping-pong only made things worse in terms of overruns and underruns, not better. Anyone who know why the ping-pong was implemented and what kind of usage it was intended for? Mike. -- 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] [RFC] usb: dwc3: removal of assumption that usb3 phy always present
DRA7XX has several USB OTG subsystems. USB_OTG_SS1 includes a USB1 and USB2
phy. USB_OTG_SS2 includes only a USB2 phy.
This patch allows the dwc3 probe to continue if a usb3_phy is not found.
This patch currently works for DRA7XX and submitted in the interim a nicer
method emerges.
Signed-off-by: Ruchika Kharwar ruch...@ti.com
---
drivers/usb/dwc3/core.c | 38 --
drivers/usb/dwc3/gadget.c | 11 ---
2 files changed, 28 insertions(+), 21 deletions(-)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 358375e..feea92d 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -100,7 +100,10 @@ static void dwc3_core_soft_reset(struct dwc3 *dwc)
dwc3_writel(dwc-regs, DWC3_GUSB2PHYCFG(0), reg);
usb_phy_init(dwc-usb2_phy);
- usb_phy_init(dwc-usb3_phy);
+
+ if (!IS_ERR(dwc-usb3_phy))
+ usb_phy_init(dwc-usb3_phy);
+
mdelay(100);
/* Clear USB3 PHY reset */
@@ -360,7 +363,9 @@ err0:
static void dwc3_core_exit(struct dwc3 *dwc)
{
usb_phy_shutdown(dwc-usb2_phy);
- usb_phy_shutdown(dwc-usb3_phy);
+
+ if (!IS_ERR(dwc-usb3_phy))
+ usb_phy_shutdown(dwc-usb3_phy);
}
#define DWC3_ALIGN_MASK(16 - 1)
@@ -450,22 +455,13 @@ static int dwc3_probe(struct platform_device *pdev)
}
if (IS_ERR(dwc-usb3_phy)) {
- ret = PTR_ERR(dwc-usb3_phy);
-
- /*
-* if -ENXIO is returned, it means PHY layer wasn't
-* enabled, so it makes no sense to return -EPROBE_DEFER
-* in that case, since no PHY driver will ever probe.
-*/
- if (ret == -ENXIO)
- return ret;
-
- dev_err(dev, no usb3 phy configured\n);
- return -EPROBE_DEFER;
+ dev_dbg(dev, no usb3 phy configured, possibly absent\n);
}
usb_phy_set_suspend(dwc-usb2_phy, 0);
- usb_phy_set_suspend(dwc-usb3_phy, 0);
+
+ if (!IS_ERR(dwc-usb3_phy))
+ usb_phy_set_suspend(dwc-usb3_phy, 0);
spin_lock_init(dwc-lock);
platform_set_drvdata(pdev, dwc);
@@ -604,7 +600,9 @@ static int dwc3_remove(struct platform_device *pdev)
struct dwc3 *dwc = platform_get_drvdata(pdev);
usb_phy_set_suspend(dwc-usb2_phy, 1);
- usb_phy_set_suspend(dwc-usb3_phy, 1);
+
+ if (!IS_ERR(dwc-usb3_phy))
+ usb_phy_set_suspend(dwc-usb3_phy, 1);
pm_runtime_put(pdev-dev);
pm_runtime_disable(pdev-dev);
@@ -700,7 +698,9 @@ static int dwc3_suspend(struct device *dev)
dwc-gctl = dwc3_readl(dwc-regs, DWC3_GCTL);
spin_unlock_irqrestore(dwc-lock, flags);
- usb_phy_shutdown(dwc-usb3_phy);
+ if (!IS_ERR(dwc-usb3_phy))
+ usb_phy_shutdown(dwc-usb3_phy);
+
usb_phy_shutdown(dwc-usb2_phy);
return 0;
@@ -711,7 +711,9 @@ static int dwc3_resume(struct device *dev)
struct dwc3 *dwc = dev_get_drvdata(dev);
unsigned long flags;
- usb_phy_init(dwc-usb3_phy);
+ if (!IS_ERR(dwc-usb3_phy))
+ usb_phy_init(dwc-usb3_phy);
+
usb_phy_init(dwc-usb2_phy);
msleep(100);
diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
index b5e5b35..7ca3745 100644
--- a/drivers/usb/dwc3/gadget.c
+++ b/drivers/usb/dwc3/gadget.c
@@ -2176,7 +2176,9 @@ static void dwc3_gadget_reset_interrupt(struct dwc3 *dwc)
if (dwc-revision DWC3_REVISION_194A) {
/* Resume PHYs */
dwc3_gadget_usb2_phy_suspend(dwc, false);
- dwc3_gadget_usb3_phy_suspend(dwc, false);
+
+ if (!IS_ERR(dwc-usb3_phy))
+ dwc3_gadget_usb3_phy_suspend(dwc, false);
}
if (dwc-gadget.speed != USB_SPEED_UNKNOWN)
@@ -2231,7 +2233,8 @@ static void dwc3_gadget_phy_suspend(struct dwc3 *dwc, u8
speed)
case USB_SPEED_HIGH:
case USB_SPEED_FULL:
case USB_SPEED_LOW:
- dwc3_gadget_usb3_phy_suspend(dwc, true);
+ if (!IS_ERR(dwc-usb3_phy))
+ dwc3_gadget_usb3_phy_suspend(dwc, true);
break;
}
}
@@ -2649,7 +2652,9 @@ int dwc3_gadget_init(struct dwc3 *dwc)
/* Enable USB2 LPM and automatic phy suspend only on recent versions */
if (dwc-revision = DWC3_REVISION_194A) {
dwc3_gadget_usb2_phy_suspend(dwc, false);
- dwc3_gadget_usb3_phy_suspend(dwc, false);
+
+ if (!IS_ERR(dwc-usb3_phy))
+ dwc3_gadget_usb3_phy_suspend(dwc, false);
}
ret = usb_add_gadget_udc(dwc-dev, dwc-gadget);
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2] drivers: mtd: spinand: Add generic spinand frameowrk.
Hello,
Le jeudi 4 juillet 2013 10:13:43 Sourav Poddar a écrit :
Can this somehow be made a runtime thing?
Ahh..I think we might opt for a device tree entry and based on that
check for ECC.
Ok, sounds good too.
[snip]
+ if (count oob_num ops-oobbuf chip-oobbuf) {
+ int size;
+ int offset, len, temp;
+
+ /* repack spare to oob */
+ memset(chip-oobbuf, 0,
info-ecclayout-oobavail);
+
+ temp = 0;
+ offset = info-ecclayout-oobfree[0].offset;
+ len = info-ecclayout-oobfree[0].length;
+ memcpy(chip-oobbuf + temp,
+ chip-buf + info-page_main_size +
offset, len);
Sounds like a for look might be useful here
I dont think so, there is a while loop above under which it happens.
We are increasing count at the bottom of the while loop. So, I think
this should work fine.
What I meant here, is that you could use a for loop to repeat 4 times the same
following pattern, such that it becomes:
for (j = 0; j 4; j++0 {
temp += len;
offset = info-ecclayout-oobfree[j].offset;
len = info-ecclayout-oobfree[j].length;
memcpy(chip-oobbuf + temp,
chip-buf + info-page_main_size + offset, len);
}
Or even make it a helper function which is inlined if that is deemed more
elegant.
--
Florian
--
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: omap4 ehci sporadic resume issue
Hi On 07/02/2013 05:03 PM, Roger Quadros wrote: On 07/02/2013 05:49 PM, Michael Trimarchi wrote: Hi Roger On 07/02/2013 04:42 PM, Roger Quadros wrote: On 06/28/2013 07:47 PM, Michael Trimarchi wrote: Hi When you said earlier that the problem doesn't happen when one of the ULPIs is used did you try both of them individually. e.g. case 1: port 1 only enabled, case 2: port 2 only enabled. Did it work in both the cases? Yes, so I don't think could be a problem of ulpi pins and why this happen on both at the same time? Seems more connected to somenthing else. Right. Seems to be related to two things. OFF Mode and 2 ports being used simultaneously. I'm not sure how to go about fixing this. How important is OFF Mode for your application. Can you keep it always disabled? Right now I delivery without off mode. I will try to fix in long run the usb and I think that it could be a good platform to test omap4 mainline. Yes, our aim is to get it working with mainline as well. Last question: If one domain is in RET mode and not OFF mode what happen during SAR restore in OFF mode? SAR restore will only happen when the Device enters OFF mode. Device OFF mode can only be reached when all voltage domains are switched OFF and that would depend if all power domains entered OFF or not. Just a simplistic explanation. You can refer to chapter 3.9.3 Device OFF State Management in the TRM. What happen if we ask to go in off mode for all domains but one doesn't go in off mode so the device will not go in off mode and the sar will not be used? How can work the restore? I have added a check of CM_RESTORE_ST. This register need to be clear before going in OFF mode and then show if the status of phase1 2a and 2b is completed. So before proceed with system resume and after resetting OFF_MODE bit I have tried to wait on this register, but without success. Michael cheers, -roger -- 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 01/22] mfd/ti_am335x_tscadc: remove regmap
Sorry for the long pause… On 06/17/2013 06:03 PM, Mark Brown wrote: This is a lot of for a simple mmio access. In terms of performance: If I add a trace point to my read and write I have still less code which is called and it can be disabled. This regmap overhead is always there chasing pointers. Equally well what you're implementing here is support for something that's typically implemented with an I2C or SPI control interface so you're already going to be quite a way ahead of the norm. This is part of what's confusing me, usually for this application things aren't that bad performance wise even on a massively slower bus. If all you're saying here is that there's some overhead that's fine if a bit surprising, but the way you're talking made it sound like there was some issue that made the API actually unusable. No, sorry for that confusion. I had a problem with the locking in irq context, changed the driver pointed out the problem, been told that there is a fix, applied it, never complained again. This is simply about I am forced to use regmap and I don't agree with it. As I said before: I doubt that you get this regmap access in an one GiB network driver and in turn remove their trace points to register access. Well, of course for that sort of thing the general trick is not to talk to the hardware at all and do as much as possible with memory that the hardware can DMA - there's actually still non-trivial costs in talking over the buses. That is true but even while doing DMA you have enough handshake with the HW to trigger the transfer and if you are lucky your DMA descriptors are in cached memory. Please don't get me wrong: It is still nice for slow buses and this ADC driver isn't anything close to high performance like a 1GiB network driver but it adds a lot of unwanted overhead which I prefer not to have. OK, but equally well remember that from a subsystem maintainer point of view having things factored out is a win in itself; for example with the MFDs locking on the register I/O has been a persistent issue in the past. I agree with that. But: The driver here does not use atomic updates but read followed by write so your locking here is futile. So the API/regmap alone does not make it right. And look: the MFD part uses regmap. Its children (IIO input) do not use it. After I told this Samuel he said that it is okay. So here I am. Using regmap in MFD which is only used once on init and never again. It has regmap. The register access in both child driver is split making sure they do not use the same ones. I added one function which writes a common register. That one is reset after an operation and needs to be written by the currently active child so the HW continues to work. Haven't seen anything close to it in regmap. I ask, politely I hope, to get this patch in and remove regmap since none of its features are used in this driver. Sebastian -- 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 01/22] mfd/ti_am335x_tscadc: remove regmap
On Thu, Jul 04, 2013 at 11:02:41AM +0200, Sebastian Andrzej Siewior wrote: The driver here does not use atomic updates but read followed by write so your locking here is futile. So the API/regmap alone does not make Doesn't that sound like the driver ought to be using a r/m/w primitive though? it right. And look: the MFD part uses regmap. Its children (IIO input) do not use it. After I told this Samuel he said that it is okay. Again I think the point here was that they probably ought to do so. But I guess if you're saying there's no problem that's fine... signature.asc Description: Digital signature
Re: [alsa-devel] Query on Audio DMA using DMAEngine
On Thu, Jul 04, 2013 at 07:56:25AM +0200, Mike Looijmans wrote: On 07/03/2013 08:12 PM, Mark Brown wrote: This is an application issue not a driver issue. An application that wants low latency may need high resolution information about what exactly the hardware is doing. To get low-latency, the best thing from userspace is to mmap the audio buffer, and monitor the position of the DMA transfers. If the driver reports the DMA position accurately, you can get latencies of only a few samples. I must admit that I know next to nothing about how ALSA works in userspace, but that's how DirectSound works, for example. And from what I've seen, this is also possible with ALSA. There are often hardware limitations that mean that it is not possible to know the actual position of the DMA with anything less than period accuracy - either the hardware just doesn't report the current status during a transfer or it reports something that's not quite what's needed to usefully interact with it. The former is depressingly common. The APIs can support peering at the current position but it's not something that a portable application should be relying on. Even without that - I tried with small periods of only 40 samples, this invariably fails on the current driver, with or without the ping-ping. Using the cyclic DMA I had no problem using such small periods. The period size is generally orthogonal to decisions about using cyclic DMA. signature.asc Description: Digital signature
Re: [alsa-devel] Query on Audio DMA using DMAEngine
On Thu, Jul 04, 2013 at 08:06:34AM +0200, Mike Looijmans wrote: In any case, using the IRAM directly might have some use, because you don't have to compete for the DDRRAM with other devices. But I never understood what the ping-ping via IRAM was supposed to accomplish, I don't see why McASP - IRAM - DDRRAM (or the other way around) would be better than just McASP - DDRRAM. Especially since the McASP has a built-in 256 byte FIFO buffer on both channels. In all my measurements, using the IRAM ping-pong only made things worse in terms of overruns and underruns, not better. Anyone who know why the ping-pong was implemented and what kind of usage it was intended for? Pushing the audio through some static RAM is normally implemented in order to save power - when doing this you can put the dynamic RAM into a lower power state for more of the time, only waking it up to burst data to or from the static RAM (assuming an otherwise idle system). This is more normally used for playback than for capture but the same idea applies in both cases. signature.asc Description: Digital signature
Re: [alsa-devel] Query on Audio DMA using DMAEngine
On 7/4/2013 11:36 AM, Mike Looijmans wrote: On 07/03/2013 07:55 PM, Joel Fernandes wrote: Copying some more lists are we're also discussing the DMA controller in the SoCs. Thanks. On 07/03/2013 04:43 AM, Mark Brown wrote: On Wed, Jul 03, 2013 at 11:09:22AM +0200, Lars-Peter Clausen wrote: On 07/02/2013 02:13 PM, Mark Brown wrote: This sort of cyclic thing tends to be best, ideally you don't need interrupts at all (other than a timer). Yes, this is usually how it is done. But I'm wondering maybe the EDMA controller only has a small total amount of slots available. Well, you don't need particularly many slots so long as you can cope with a large period size. Hi Mark, When would it not be possible to cope with a large period size? Are there any guidelines on what to consider when fixing a period size? I see tegra and aux1x go upto .period_bytes_min = 1024 About slots, following are no.of slots on some SoCs with EDMA: am1808 - 96 slots available + 32 taken up for channel but can be reused with some changes. am335x - 172 slots available + 64 taken up for channels On a slightly different note, about buffer_bytes_max, is there any drawback to setting it to a smaller value? Currently 128K is about what is used on davinci-pcm. My idea is to map to do the direct mapping to IRAM if the IRAM transfers are really what are preventing the under runs, but 128K will be too much for the buffer as we don't have that much IRAM infact it is just the boundary on am33xx (128K) In any case, using the IRAM directly might have some use, because you don't have to compete for the DDRRAM with other devices. But I never understood what the ping-ping via IRAM was supposed to accomplish, I don't see why McASP - IRAM - DDRRAM (or the other way around) would be better than just McASP - DDRRAM. Especially since the McASP has a built-in 256 byte FIFO buffer on both channels. In all my measurements, using the IRAM ping-pong only made things worse in terms of overruns and underruns, not better. Anyone who know why the ping-pong was implemented and what kind of usage it was intended for? McBSP peripheral that was included in the DaVinci devices like DM644x dis not come with FIFO. Due to latency of DDR accesses, there were channel swaps observed due to lost samples on these devices and IRAM implementation helped there. Thanks, Sekhar -- 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 04/22] input/ti_am33x_tsc: Order of TSC wires, made configurable
On 6/11/2013 5:00 PM, Sebastian Andrzej Siewior wrote: From: Patil, Rachna rac...@ti.com The current driver expected touchscreen input wires(XP,XN,YP,YN) to be connected in a particular order. Making changes to accept this as platform data The platform data part of this driver will never get used since it is used on DT-only platforms (and future platforms will all be DT-only). You should get rid of it as it will save you some code. Thanks, Sekhar -- 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 01/22] mfd/ti_am335x_tscadc: remove regmap
On 07/04/2013 12:45 PM, Mark Brown wrote: On Thu, Jul 04, 2013 at 11:02:41AM +0200, Sebastian Andrzej Siewior wrote: The driver here does not use atomic updates but read followed by write so your locking here is futile. So the API/regmap alone does not make Doesn't that sound like the driver ought to be using a r/m/w primitive though? It does this in the init phase before the child devices are created so no harm is done. I just wanted to say that regmap alone does not help as long as the use simply replaces all reads writes with regmap reads writes. it right. And look: the MFD part uses regmap. Its children (IIO input) do not use it. After I told this Samuel he said that it is okay. Again I think the point here was that they probably ought to do so. It didn't sound that way. But I guess if you're saying there's no problem that's fine... Thank you. Samuel, is it okay if I repost the patch? It can wait till past -rc1 if you are willing to take it. Sebastian -- 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 04/22] input/ti_am33x_tsc: Order of TSC wires, made configurable
On 07/04/2013 01:14 PM, Sekhar Nori wrote: On 6/11/2013 5:00 PM, Sebastian Andrzej Siewior wrote: From: Patil, Rachna rac...@ti.com The current driver expected touchscreen input wires(XP,XN,YP,YN) to be connected in a particular order. Making changes to accept this as platform data The platform data part of this driver will never get used since it is used on DT-only platforms (and future platforms will all be DT-only). You should get rid of it as it will save you some code. If you follow the series you will notice that the platform bits are removed later. Should I have overlooked something please say so. Thanks, Sekhar Sebastian -- 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/4] arm: omap: Add phy binding info for musb in plat data
* Kishon Vijay Abraham I kis...@ti.com [130619 01:58]:
In order for controllers to get PHY in case of non dt boot, the phy
binding information (phy label) should be added in the platform
data of the controller.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Tested-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/usb-musb.c |6 +-
include/linux/usb/musb.h |3 +++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 3242a55..5ddbe39 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -85,8 +85,12 @@ void __init usb_musb_init(struct omap_musb_board_data
*musb_board_data)
musb_plat.mode = board_data-mode;
musb_plat.extvbus = board_data-extvbus;
- if (cpu_is_omap44xx())
+ if (cpu_is_omap44xx()) {
musb_plat.has_mailbox = true;
+ musb_plat.phy_name = omap-usb2;
+ } else if (cpu_is_omap34xx()) {
+ musb_plat.phy_name = twl4030;
+ }
if (soc_is_am35xx()) {
oh_name = am35x_otg_hs;
Care to refresh this patch against the current mainline tree?
Now omap4 is DT only, so this part won't apply. Mostly I'm wondering
what the phy_name should be for am35xx that's not covered by this
patch.
Also let me know if the last patch is safe to queue alone as a fix
or if it depends on the driver related changes in this series.
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 1/1] ARM: OMAP3: igep0020: Set DSS pins in correct mux mode.
* Javier Martinez Canillas javier.marti...@collabora.co.uk [130619 09:31]: From: Enric Balletbo i Serra eballe...@iseebcn.com Platform code used to depend on bootloadres for correctly setting the mux pin modes. But bootloaders should only set the minimum required mux pins. So, DSS mux pins are not set in U-Boot anymore and video display is broken on IGEPv2 when booting with newer U-Boot versions. Setup the DSS pin muxes to enable display functionality. Signed-off-by: Enric Balletbo i Serra eballe...@iseebcn.com Reviewed-by: Javier Martinez Canillas javier.marti...@collabora.co.uk --- Tony, Can you please take this until we have finished the OMAP3 migration to DT? I think it falls under the critical fix category that you were talking about. Thanks, yes I'll apply it into omap-for-v3.11/fixes. Other than DSS and the pending pinctrl-single patches, we have off-idle working for omap3 with DT, so there really are no reasons to not make omap3 DT only very soon. 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] ARM: OMAP: Cocci spatch ptr_ret.spatch
* Kevin Hilman khil...@linaro.org [130603 14:23]: Thomas Meyer tho...@m3y3r.de writes: Signed-off-by: Thomas Meyer tho...@m3y3r.de Could use a changelog, but otherwise Acked-by: Kevin Hilman khil...@linaro.org I've updated the patch to use subject as the changelog, applying into omap-for-v3.11/fixes. 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] ARM: OMAP2+: timer: initialize before using oh_name
* Jon Hunter jgchun...@gmail.com [130528 14:26]:
On 28/05/13 07:24, Afzal Mohammed wrote:
of_property_read_string_index(...,oh_name) in omap_dm_timer_init_one
does not alter the value of 'oh_name' even if the relevant function
fails and as 'oh_name' in stack may have a non-zero value, it would
be misunderstood by timer code that DT has specified ti,hwmod
property for timer. 'oh_name' in this scenario would be a junk value,
this would result in module not being enabled by hwmod API's for
timer, and in turn crash.
Signed-off-by: Afzal Mohammed af...@ti.com
---
arch/arm/mach-omap2/timer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/timer.c b/arch/arm/mach-omap2/timer.c
index f8b23b8..8e0c390 100644
--- a/arch/arm/mach-omap2/timer.c
+++ b/arch/arm/mach-omap2/timer.c
@@ -220,7 +220,7 @@ static int __init omap_dm_timer_init_one(struct
omap_dm_timer *timer,
int posted)
{
char name[10]; /* 10 = sizeof(gptXX_Xck0) */
- const char *oh_name;
+ const char *oh_name = NULL;
struct device_node *np;
struct omap_hwmod *oh;
struct resource irq, mem;
Thanks!
Acked-by: Jon Hunter jgchun...@gmail.com
Thanks, applying into omap-for-v3.11/fixes.
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] ARM: OMAP2+: Remove obsolete Makefile line
* Paul Bolle pebo...@tiscali.nl [130530 04:26]: The OMAP runtime PM implementation was removed in v3.0. But one Makefile line, which was used to tweak CFLAGS, was overlooked. Remove it too. Signed-off-by: Paul Bolle pebo...@tiscali.nl --- Untested. This cleans up after commit 638080c37a (OMAP2+ / PM: move runtime PM implementation to use device power domains). Thanks, applying into omap-for-v3.11/fixes. Tony arch/arm/mach-omap2/Makefile | 4 1 file changed, 4 deletions(-) diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index 55a9d67..7279fa8 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -93,10 +93,6 @@ obj-$(CONFIG_POWER_AVS_OMAP_CLASS3)+= smartreflex-class3.o AFLAGS_sleep24xx.o :=-Wa,-march=armv6 AFLAGS_sleep34xx.o :=-Wa,-march=armv7-a$(plus_sec) -ifeq ($(CONFIG_PM_VERBOSE),y) -CFLAGS_pm_bus.o += -DDEBUG -endif - endif ifeq ($(CONFIG_CPU_IDLE),y) -- 1.7.11.7 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 5/6] arm: omap2plus_defconfig: enable TI bandgap driver
* Eduardo Valentin eduardo.valen...@ti.com [130618 13:33]: Tony, On 07-06-2013 16:46, Eduardo Valentin wrote: Enable the bandgap driver for TI SoCs thermal support. Cc: Russell King li...@arm.linux.org.uk Cc: Tony Lindgren t...@atomide.com Cc: Javier Martinez Canillas javier.marti...@collabora.co.uk Cc: AnilKumar Ch anilku...@ti.com Cc: Santosh Shilimkar santosh.shilim...@ti.com Cc: Tomi Valkeinen tomi.valkei...@ti.com Cc: linux-arm-ker...@lists.infradead.org Cc: linux-ker...@vger.kernel.org Signed-off-by: Eduardo Valentin eduardo.valen...@ti.com Is it possible for you to queue this one and patch 6 for 3.11? Yes thanks applying into omap-for-v3.11/fixes. 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] N900: enable N900-specific drivers even if device tree is enabled
* Pavel Machek pa...@ucw.cz [130701 14:21]:
We still need video sound drivers with device tree enabled.
Signed-off-by: Pavel Machek pa...@ucw.cz
Thanks, applying this into omap-for-v3.11/fixes. Benoit should
queue the .dts related changes.
Tony
---
Patch against 3.10.
--- linux-delme-clean//arch/arm/mach-omap2/board-rx51-video.c 2013-07-01
21:51:07.0 +0200
+++ linux-delme/arch/arm/mach-omap2/board-rx51-video.c2013-07-01
22:50:27.0 +0200
@@ -61,7 +61,7 @@
static int __init rx51_video_init(void)
{
- if (!machine_is_nokia_rx51())
+ if (!machine_is_nokia_rx51()
!of_machine_is_compatible(nokia,omap3-n900))
return 0;
if (omap_mux_init_gpio(RX51_LCD_RESET_GPIO, OMAP_PIN_OUTPUT)) {
diff -urN linux-delme-clean//sound/soc/omap/rx51.c
linux-delme/sound/soc/omap/rx51.c
--- linux-delme-clean//sound/soc/omap/rx51.c 2013-07-01 21:54:49.0
+0200
+++ linux-delme/sound/soc/omap/rx51.c 2013-07-01 22:50:27.0 +0200
@@ -396,7 +396,7 @@
{
int err;
- if (!machine_is_nokia_rx51())
+ if (!machine_is_nokia_rx51()
!of_machine_is_compatible(nokia,omap3-n900))
return -ENODEV;
err = gpio_request_one(RX51_TVOUT_SEL_GPIO,
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: OMAP5: Enable Cortex A15 errata 798181
* Santosh Shilimkar santosh.shilim...@ti.com [130703 07:01]: Ping.. Applying into omap-for-v3.11/fixes now that all our pending branches have been merged. 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 -next] ARM: OMAP2+: devices: remove duplicated include from devices.c
* Wei Yongjun weiyj...@gmail.com [130619 17:07]: From: Wei Yongjun yongjun_...@trendmicro.com.cn Remove duplicated include. Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn Thanks applying into omap-for-v3.11/fixes. Looks like the reboot.h duplicate has already been removed. Regards, Tony --- arch/arm/mach-omap2/devices.c | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c index c0f99ab..8349238 100644 --- a/arch/arm/mach-omap2/devices.c +++ b/arch/arm/mach-omap2/devices.c @@ -15,7 +15,6 @@ #include linux/io.h #include linux/clk.h #include linux/err.h -#include linux/gpio.h #include linux/slab.h #include linux/of.h #include linux/pinctrl/machine.h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/4] Cleanup PRM and CM regbit headers
* Rajendra Nayak rna...@ti.com [130625 01:49]: On Tuesday 25 June 2013 12:44 PM, Tony Lindgren wrote: Rajendra Nayak (4): ARM: OMAP2: PRM/CM: Cleanup unused header contents ARM: OMAP3: PRM/CM: Cleanup unused header contents ARM: OMAP4: PRM/CM: Cleanup unused header contents ARM: OMAP5: PRM/CM: Cleanup unused header contents arch/arm/mach-omap2/cm-regbits-24xx.h | 317 arch/arm/mach-omap2/cm-regbits-33xx.h | 758 - arch/arm/mach-omap2/cm-regbits-34xx.h | 631 arch/arm/mach-omap2/cm-regbits-44xx.h | 1557 --- arch/arm/mach-omap2/cm-regbits-54xx.h | 1632 --- arch/arm/mach-omap2/prm-regbits-24xx.h | 246 --- arch/arm/mach-omap2/prm-regbits-33xx.h | 305 arch/arm/mach-omap2/prm-regbits-34xx.h | 480 -- arch/arm/mach-omap2/prm-regbits-44xx.h | 2225 -- arch/arm/mach-omap2/prm-regbits-54xx.h | 2677 10 files changed, 10828 deletions(-) If things build and work after applying this, I suggest we send them as a clean-up branch right after -rc1. They build fine, and I boot tested on the omap4/5 boards that I have too. (I had the out of tree clock data pulled in for omap5 before I did this cleanup). It seems that build testing and then randconfig testing should be enough for these if they are unused and only removal. Right, I'll do more testing and even though they should just boot fine on the omap2/3 boards too since all thats removed is anyway unused, I will still do more sanity test before posting them on -rc1. Looks like we have all the pending stuff merged already, this would probably be a good time to post a pull request for these. 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: [PATCHv2] ARM: OMAP: build mach-omap code only if needed
* Tony Lindgren t...@atomide.com [130625 00:34]: * Arnd Bergmann a...@arndb.de [130624 07:25]: If we build a kernel with CONFIG_ARCH_OMAP2PLUS enabled but all of the individual SoCs disabled, we run into a large number of link errors because if incorrect dependencies: arch/arm/mach-omap2/built-in.o: In function `_add_initiator_dep': arch/arm/mach-omap2/omap_hwmod.c:691: undefined reference to `clkdm_add_sleepdep' arch/arm/mach-omap2/built-in.o: In function `_del_initiator_dep': arch/arm/mach-omap2/omap_hwmod.c:720: undefined reference to `clkdm_del_sleepdep' arch/arm/mach-omap2/built-in.o: In function `_enable': arch/arm/mach-omap2/omap_hwmod.c:2145: undefined reference to `clkdm_in_hwsup' arch/arm/mach-omap2/omap_hwmod.c:2147: undefined reference to `clkdm_hwmod_enable' arch/arm/mach-omap2/omap_hwmod.c:2191: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/omap_hwmod.c:2146: undefined reference to `clkdm_missing_idle_reporting' arch/arm/mach-omap2/built-in.o: In function `_idle': arch/arm/mach-omap2/omap_hwmod.c:2235: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/built-in.o: In function `_shutdown': arch/arm/mach-omap2/omap_hwmod.c:2338: undefined reference to `clkdm_hwmod_disable' arch/arm/mach-omap2/built-in.o: In function `omap_hwmod_get_context_loss_count': arch/arm/mach-omap2/omap_hwmod.c:4071: undefined reference to `pwrdm_get_context_loss_count' arch/arm/mach-omap2/built-in.o: In function `omap_pm_clkdms_setup': arch/arm/mach-omap2/pm.c:114: undefined reference to `clkdm_allow_idle' arch/arm/mach-omap2/pm.c:117: undefined reference to `clkdm_sleep' arch/arm/mach-omap2/built-in.o: In function `omap2_common_pm_late_init': arch/arm/mach-omap2/pm.c:294: undefined reference to `omap_voltage_late_init' arch/arm/mach-omap2/built-in.o: In function `omap2_gpio_dev_init': arch/arm/mach-omap2/gpio.c:133: undefined reference to `pwrdm_can_ever_lose_context' We can avoid this if we make CONFIG_ARCH_OMAP2PLUS a silent option that gets enabled any time that one of the SoC versions is enabled. /me hopes this does the trick finally ;) I could not apply this to anything I tried though.. Which branch is this against? Ping, do you have updated patche(s) available as we discussed on IRC? 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: [-next PATCH 0/2] ARM: OMAP5: fix build breakage due to SCU usage
* Nishanth Menon n...@ti.com [130701 08:41]: Tony, Any chance of picking these up? Thanks yes applying into omap-for-v3.11/fixes now that the pending branches have been merged. 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 1/2] ARM: configs: Enable TI_EDMA in omap2plus_defconfig
* Joel Fernandes jo...@ti.com [130626 20:48]: Build EDMA in by default to avoid fewer people stepping on their toes with broken DMA on drivers needing EDMA. Thanks applying this one into omap-for-v3.11/fixes. 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] ARM: OMAP2+: omap2plus_defconfig: Enable appended DTB support
* Tom Rini tr...@ti.com [130701 06:19]: As this config must support boards which cannot support separate device trees, enable support for appended ones. This can cause things to go wrong when DTB is not appended for mistaking the memory as an appended DTB, especially when doing a warm reset. But as we need this in practise for older platforms, let's add it. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/4] arm: omap: Add phy binding info for musb in plat data
Hi,
On Thursday 04 July 2013 05:14 PM, Tony Lindgren wrote:
* Kishon Vijay Abraham I kis...@ti.com [130619 01:58]:
In order for controllers to get PHY in case of non dt boot, the phy
binding information (phy label) should be added in the platform
data of the controller.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
Acked-by: Felipe Balbi ba...@ti.com
Tested-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/mach-omap2/usb-musb.c |6 +-
include/linux/usb/musb.h |3 +++
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/usb-musb.c b/arch/arm/mach-omap2/usb-musb.c
index 3242a55..5ddbe39 100644
--- a/arch/arm/mach-omap2/usb-musb.c
+++ b/arch/arm/mach-omap2/usb-musb.c
@@ -85,8 +85,12 @@ void __init usb_musb_init(struct omap_musb_board_data
*musb_board_data)
musb_plat.mode = board_data-mode;
musb_plat.extvbus = board_data-extvbus;
- if (cpu_is_omap44xx())
+ if (cpu_is_omap44xx()) {
musb_plat.has_mailbox = true;
+ musb_plat.phy_name = omap-usb2;
+ } else if (cpu_is_omap34xx()) {
+ musb_plat.phy_name = twl4030;
+ }
if (soc_is_am35xx()) {
oh_name = am35x_otg_hs;
Care to refresh this patch against the current mainline tree?
I'll do that on monday as I'm not in office and I dont have any boards
to test at my disposal now.
Now omap4 is DT only, so this part won't apply. Mostly I'm wondering
what the phy_name should be for am35xx that's not covered by this
patch.
am35xx doesn't have a separate PHY driver yet (I guess the programming
is done in the controller code now). So this binding is not needed for
am35xx.
Also let me know if the last patch is safe to queue alone as a fix
or if it depends on the driver related changes in this series.
No. The last patch is kind-of cleanup needed after applying the first
3 patches. It's better it's applied along with the other patches.
Thanks
Kishon
--
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 0/4] Cleanup PRM and CM regbit headers
On Thursday 04 July 2013 05:28 PM, Tony Lindgren wrote: * Rajendra Nayak rna...@ti.com [130625 01:49]: On Tuesday 25 June 2013 12:44 PM, Tony Lindgren wrote: Rajendra Nayak (4): ARM: OMAP2: PRM/CM: Cleanup unused header contents ARM: OMAP3: PRM/CM: Cleanup unused header contents ARM: OMAP4: PRM/CM: Cleanup unused header contents ARM: OMAP5: PRM/CM: Cleanup unused header contents arch/arm/mach-omap2/cm-regbits-24xx.h | 317 arch/arm/mach-omap2/cm-regbits-33xx.h | 758 - arch/arm/mach-omap2/cm-regbits-34xx.h | 631 arch/arm/mach-omap2/cm-regbits-44xx.h | 1557 --- arch/arm/mach-omap2/cm-regbits-54xx.h | 1632 --- arch/arm/mach-omap2/prm-regbits-24xx.h | 246 --- arch/arm/mach-omap2/prm-regbits-33xx.h | 305 arch/arm/mach-omap2/prm-regbits-34xx.h | 480 -- arch/arm/mach-omap2/prm-regbits-44xx.h | 2225 -- arch/arm/mach-omap2/prm-regbits-54xx.h | 2677 10 files changed, 10828 deletions(-) If things build and work after applying this, I suggest we send them as a clean-up branch right after -rc1. They build fine, and I boot tested on the omap4/5 boards that I have too. (I had the out of tree clock data pulled in for omap5 before I did this cleanup). It seems that build testing and then randconfig testing should be enough for these if they are unused and only removal. Right, I'll do more testing and even though they should just boot fine on the omap2/3 boards too since all thats removed is anyway unused, I will still do more sanity test before posting them on -rc1. Looks like we have all the pending stuff merged already, this would probably be a good time to post a pull request for these. Ok, will do, thanks. Paul/Benoit, Should I also drop these lines from the file headers since they are no longer same as the outputs from autogen files? * This file is automatically generated from the OMAP hardware databases. * We respectfully ask that any modifications to this file be coordinated * with the public linux-omap@vger.kernel.org mailing list and the * authors above to ensure that the autogeneration scripts are kept * up-to-date with the file contents. regards, Rajendra 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 04/22] input/ti_am33x_tsc: Order of TSC wires, made configurable
On 7/4/2013 5:03 PM, Sebastian Andrzej Siewior wrote: On 07/04/2013 01:14 PM, Sekhar Nori wrote: On 6/11/2013 5:00 PM, Sebastian Andrzej Siewior wrote: From: Patil, Rachna rac...@ti.com The current driver expected touchscreen input wires(XP,XN,YP,YN) to be connected in a particular order. Making changes to accept this as platform data The platform data part of this driver will never get used since it is used on DT-only platforms (and future platforms will all be DT-only). You should get rid of it as it will save you some code. If you follow the series you will notice that the platform bits are removed later. Should I have overlooked something please say so. Yes, I noticed that after sending the mail. To me it does not make sense to make changes to accept something as platform data only to remove platform data itself later. May be reorder the series to move this to after platform data removal - that way any platform data related changes in the patch will have to go away. Thanks, Sekhar -- 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] ARM: OMAP: fix return value check in omap_device_build_from_dt()
From: Wei Yongjun yongjun_...@trendmicro.com.cn
In case of error, the function omap_device_alloc() returns ERR_PTR()
and never returns NULL. The NULL test in the return value check
should be replaced with IS_ERR().
Signed-off-by: Wei Yongjun yongjun_...@trendmicro.com.cn
---
arch/arm/mach-omap2/omap_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/omap_device.c
b/arch/arm/mach-omap2/omap_device.c
index 5cc9287..28e70c0 100644
--- a/arch/arm/mach-omap2/omap_device.c
+++ b/arch/arm/mach-omap2/omap_device.c
@@ -155,7 +155,7 @@ static int omap_device_build_from_dt(struct platform_device
*pdev)
}
od = omap_device_alloc(pdev, hwmods, oh_cnt);
- if (!od) {
+ if (IS_ERR(od)) {
dev_err(pdev-dev, Cannot allocate omap_device for :%s\n,
oh_name);
ret = PTR_ERR(od);
--
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 14/22] arm/am33xx: add TSC/ADC mfd device support
On 6/11/2013 5:01 PM, Sebastian Andrzej Siewior wrote:
From: Patil, Rachna rac...@ti.com
Add support for core multifunctional device along
with its clients touchscreen and ADC.
[ pa...@antoniou-consulting.com : make sure status is
set to 'disabled' in dtsi file. ]
Signed-off-by: Pantelis Antoniou pa...@antoniou-consulting.com
Signed-off-by: Patil, Rachna rac...@ti.com
Signed-off-by: Felipe Balbi ba...@ti.com
[bigeasy: add 'status = okay']
Signed-off-by: Sebastian Andrzej Siewior sebast...@breakpoint.cc
---
arch/arm/boot/dts/am335x-evm.dts | 14 ++
arch/arm/boot/dts/am33xx.dtsi| 18 ++
2 files changed, 32 insertions(+)
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 1460d9b..4ad7797 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -404,6 +404,24 @@
ti,hwmods = wkup_m3;
};
+ tscadc: tscadc@44e0d000 {
+ compatible = ti,am3359-tscadc;
+ reg = 0x44e0d000 0x1000;
+ interrupt-parent = intc;
interrupt-parent can be dropped since it will be inherited from parent.
Thanks,
Sekhar
--
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 14/22] arm/am33xx: add TSC/ADC mfd device support
On 07/04/2013 03:49 PM, Sekhar Nori wrote:
diff --git a/arch/arm/boot/dts/am33xx.dtsi b/arch/arm/boot/dts/am33xx.dtsi
index 1460d9b..4ad7797 100644
--- a/arch/arm/boot/dts/am33xx.dtsi
+++ b/arch/arm/boot/dts/am33xx.dtsi
@@ -404,6 +404,24 @@
ti,hwmods = wkup_m3;
};
+tscadc: tscadc@44e0d000 {
+compatible = ti,am3359-tscadc;
+reg = 0x44e0d000 0x1000;
+interrupt-parent = intc;
interrupt-parent can be dropped since it will be inherited from parent.
That is true. I prepare a patch for that after the merge window.
Thanks,
Sekhar
Sebastian
--
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 04/22] input/ti_am33x_tsc: Order of TSC wires, made configurable
On 07/04/2013 03:39 PM, Sekhar Nori wrote: Yes, I noticed that after sending the mail. To me it does not make sense to make changes to accept something as platform data only to remove platform data itself later. The patches were made earlier and it was easier that way to take everything and simple remove the platform part later. May be reorder the series to move this to after platform data removal - that way any platform data related changes in the patch will have to go away. Thanks, Sekhar Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/8] wlcore: set irq_flags in the board files instead of hiding behind a quirk
On Wed, 2013-07-03 at 17:12 +0200, Javier Martinez Canillas wrote:
On Wed, Jul 3, 2013 at 4:15 PM, Luciano Coelho coe...@ti.com wrote:
On Wed, 2013-07-03 at 17:03 +0300, Luciano Coelho wrote:
The platform_quirk element in the platform data was used to change the
way the IRQ is triggered. When set, the EDGE_IRQ quirk would change
the irqflags used and treat edge trigger differently from the rest.
Instead of hiding this irq flag setting behind the quirk, have the
board files set the flags during initialization. This will be more
meaningful than driver-specific quirks when we switch to DT.
Additionally, fix missing gpio_request() calls in the boarding files
(so that setting the flags actually works).
Cc: Tony Lindgren t...@atomide.com
Cc: Sekhar Nori nsek...@ti.com
Signed-off-by: Luciano Coelho coe...@ti.com
---
[...]
@@ -5928,16 +5927,21 @@ static void wlcore_nvs_cb(const struct firmware
*fw, void *context)
wlcore_adjust_conf(wl);
wl-irq = platform_get_irq(pdev, 0);
- wl-platform_quirks = pdata-platform_quirks;
wl-if_ops = pdev_data-if_ops;
- if (wl-platform_quirks WL12XX_PLATFORM_QUIRK_EDGE_IRQ)
- irqflags = IRQF_TRIGGER_RISING;
- else
- irqflags = IRQF_TRIGGER_HIGH | IRQF_ONESHOT;
+ irq_data = irq_get_irq_data(wl-irq);
+ if (!irq_data) {
+ wl1271_error(couldn't get irq data for irq %d\n, wl-irq);
+ ret = -EINVAL;
+ goto out_free_nvs;
+ }
+
+ wl-irq_flags = irqd_get_trigger_type(irq_data);
BTW, there seems to be a patch on its way to make reading the flags
easier (ie. no need to get the irq_data first):
http://mid.gmane.org/1367945288-5625-1-git-send-email-jav...@dowhile0.org
I'm not sure if this is going to be taken in, but if it does, it would
be nice to change the code here to use the new irq_get_trigger_type()
function.
That patch has been already merged in Linus tree as commit 1f6236bf
(genirq: Add irq_get_trigger_type() to get IRQ flags).
So yes, it would be better if you can use irq_get_trigger_type()
instead calling irq_get_irq_data() + irqd_get_trigger_type().
That's great, thanks! I'll make this change as soon as I get your patch
into my tree (ie. after the merge window closes).
--
Luca.
--
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 04/22] input/ti_am33x_tsc: Order of TSC wires, made configurable
On 7/4/2013 7:20 PM, Sebastian Andrzej Siewior wrote: On 07/04/2013 03:39 PM, Sekhar Nori wrote: Yes, I noticed that after sending the mail. To me it does not make sense to make changes to accept something as platform data only to remove platform data itself later. The patches were made earlier and it was easier that way to take everything and simple remove the platform part later. Okay, then. If the maintainers do not have objection, I am fine too! Regards, Sekhar -- 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: Boot hang regression 3.10.0-rc4 - 3.10.0
On 04/07/13 14:25, Mark Jackson wrote: Our custom AM335x board has been booting just fine under 3.10.0-rc4. I've just done a git pull to update to 3.10 (now that it's released) and the board now hangs. Before I start trying to bisect the issue, does anyone have an clues ? Okay ... I've now bisected it to:- a630fbfbb1beeffc5bbe542a7986bf2068874633 is the first bad commit commit a630fbfbb1beeffc5bbe542a7986bf2068874633 Author: Tony Lindgren t...@atomide.com Date: Mon Jun 10 07:39:09 2013 -0700 serial: omap: Fix device tree based PM runtime In the runtime_suspend function pdata is not being used, and also blocks the function in device tree based booting. Fix it by removing the unused pdata from the runtime_suspend function. Further, context loss count is not being passed in pdata, so let's just reinitialize the port every time for those case. This can be further optimized later on for the device tree case by adding detection for the hardware state and possibly by adding a driver specific autosuspend timeout. And doing this, we can then make the related dev_err into a dev_dbg message instead of an error. In order for the wake-up events to work, we also need to set autosuspend_timeout to -1 if 0, and also device_init_wakeup() as that's not being done by the platform init code for the device tree case. Note that this does not affect legacy booting, and in fact might make it work for the cases where the context loss info is not being passed in pdata. Thanks to Kevin Hilman khil...@linaro.org for debugging and suggesting fixes for the autosuspend_timeout and device_init_wakeup() related initializiation. Reviewed-by: Kevin Hilman khil...@linaro.org Tested-by: Kevin Hilman khil...@linaro.org Signed-off-by: Tony Lindgren t...@atomide.com Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org :04 04 38900a5a2ed6dfeb812d93bf1918725021298884 a38d3dcd46276dc27b87157fd0b1e292804c M drivers -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH V2 1/8] regulator: Introduce OMAP regulator to control PMIC over VC/VP
On Fri, Jun 21, 2013 at 04:25:42PM -0500, Nishanth Menon wrote:
+static const struct omap_pmic_info omap_twl4030_vdd1 = {
+ .slave_addr = 0x12,
+ .voltage_reg_addr = 0x00,
+ .cmd_reg_addr = 0x00,
+ .i2c_timeout_us = 200,
+ .slew_rate_uV = 4000,
+ .step_size_uV = 12500,
+ .min_uV = 60,
+ .max_uV = 145,
+ .voltage_selector_offset = 0,
+ .voltage_selector_mask = 0x7F,
+ .voltage_selector_setbits = 0x0,
+ .voltage_selector_zero = false,
+};
So, this still has the thing where all the data about the PMIC is
replicated (but now in this driver). It should be possible to pull all
the above information except possibly the I2C timeout and perhaps the
I2C address (if there's a separate control interface) from the standard
regulator core data structures for the PMIC. This would allow the
driver to Just Work with any PMIC without needing to add it in two
places.
Other than that this looks good, the only issue I see is where the
driver is getting the data from.
signature.asc
Description: Digital signature
Re: Boot hang regression 3.10.0-rc4 - 3.10.0
On 04/07/13 16:14, Mark Jackson wrote: On 04/07/13 14:25, Mark Jackson wrote: Our custom AM335x board has been booting just fine under 3.10.0-rc4. I've just done a git pull to update to 3.10 (now that it's released) and the board now hangs. Before I start trying to bisect the issue, does anyone have an clues ? Okay ... I've now bisected it to:- a630fbfbb1beeffc5bbe542a7986bf2068874633 is the first bad commit commit a630fbfbb1beeffc5bbe542a7986bf2068874633 Author: Tony Lindgren t...@atomide.com Date: Mon Jun 10 07:39:09 2013 -0700 serial: omap: Fix device tree based PM runtime However, reverting the commit does *not* fix the issue, weird !! But I have now tested:- v3.10-rc4 - works v3.10-rc5 - works v3.10-rc6 - works v3.10-rc7 - works v3.10 - works origin/master - hangs Any ideas ? -- 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 0/4] Cleanup PRM and CM regbit headers
On Thu, 4 Jul 2013, Rajendra Nayak wrote: Paul/Benoit, Should I also drop these lines from the file headers since they are no longer same as the outputs from autogen files? * This file is automatically generated from the OMAP hardware databases. * We respectfully ask that any modifications to this file be coordinated * with the public linux-omap@vger.kernel.org mailing list and the * authors above to ensure that the autogeneration scripts are kept * up-to-date with the file contents. Heh... Here's my view: You mentioned that these patches were generated with some kind of awk/grep scripting. Can you integrate that in an automated way into the autogeneration flow? If the answer is yes, then keep the header. If the answer is no, then the header should be dropped. Benoît, maybe you have an opinion too? As far as whether this should go in -rcX or not, my view is that, as a matter of policy, large changes like this should wait until v3.12. Now, having written that, I also was under the impression that the OMAP5 changes weren't going to be sent upstream unless the total diffstat would be balanced to roughly zero or negative lines. As far as I know, that didn't happen. So I guess, v3.11-rc it is... kernel development by diffstat :-( Finally, please repost the whole series once you're done with your changes, as a non-RFC, along with your pull request (if you plan to send one). I guess I should be the one to take these, since I wound up taking the OMAP5 addition... regards - Paul
Re: [PATCH v4 0/4] mtd:nand:omap2: clean-up of supported ECC schemes
On 7/3/2013 11:34 PM, Gupta, Pekon wrote:
On Wednesday 03 July 2013, Artem Bityutskiy wrote:
On Wed, 2013-07-03 at 13:16 +, Gupta, Pekon wrote:
[Pekon]: Yes, I'm not seeing these build issues, as I'm cleanly
returning from probe with pr_err(), if the required libraries (/lib/bch.c)
are not build-in the system.
---
[Patch v4 1/4]: mtd:nand:omap2: clean-up BCHx_HW and BCHx_SW ECC..
@@static int omap_nand_probe(struct platform_device *pdev)
+ default:
+ pr_err(selected ECC scheme not supported or not
enabled\n);
+ err = -EINVAL;
+ goto out_release_mem_region;
+ }
---
However, if you are still seeing this, could you please send me your
config?
I compile tested your patches too, and did not see any issues with my
omap2_defconfig.
To clarify: I'm getting this error with randconfig on today's linux-next.
I think it only happens with MTD_NAND_ECC_BCH enabled, which is not
the default in omap2_defconfig.
Arnd
Hi Arnd, Artem, Stephen,
I see the issue in linux-next/master tree..
linux-next/master has only the first [Patch v4 1/4] from the series.
Other patches [Patch v4 2/4.. 4/4] of this series were dropped,
as 'Olof Johansson' had some apprehensions about DT bindings.
http://permalink.gmane.org/gmane.linux.ports.arm.kernel/249662
As these patches are inter-dependent, so please drop the whole series
including the commit below.
fb1585b [Patch v4 1/4] mtd: nand: omap2: clean-up BCHx_HW and BCHx_SW
I'm awaiting feedbacks from 'Olof Johansson' or other DT maintainers,
once approved, I'll resend the whole series.
[PATCH v4 2/4] ARM: OMAP2+: cleaned-up DT support had the
declarations which were required for above build errors.
---
include/linux/platform_data/mtd-nand-omap2.h
enum omap_ecc {
+ /* 4-bit ECC calculation by GPMC, Error detection by Software */
+ OMAP_ECC_BCH4_CODE_HW_DETECTION_SW,
...
+ /* 8-bit ECC calculation by GPMC, Error detection by Software */
+ OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
---
But patches should not have inter dependency for compilation. It will affect
the bisect process.
Regards
Mugunthan V N
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.10-rc7
Hi On Mon, 1 Jul 2013, Felipe Balbi wrote: On Mon, Jul 01, 2013 at 07:48:50PM +, Paul Walmsley wrote: Boot to userspace: FAIL ( 2/12): 37xxevm, am335xbonelt quoting part of [1] | U-Boot# tftp 0x8200 am335x-boneblack.dtb | link up on port 0, speed 100, full duplex | Using cpsw device | TFTP from server 192.168.57.1; our IP address is 192.168.57.138 | Filename 'am335x-boneblack.dtb'. Where are you taking am335x-boneblack.dtb from ? It's not in mainline v3.10-rc7 kernel: As mentioned in my earlier reply: http://www.spinics.net/lists/arm-kernel/msg255055.html my earlier test boots were with the am335x-boneblack.dtb from the ti-linux-3.8.y tree from Vaibhav's github, since that was the only DTB that I was able to get any kernel to boot with. The am33xx_only/appended DTB issues don't apply to this board since it's booted with detached DTB and omap2plus_defconfig. Anyway, just retried it with the mainline am335x-bone.dtb file with v3.10, and the board comes up now. So that's good, will switch to am335x-bone.dtb for the testing restate jobs to be run for BeagleBone-white, and let's see what previous kernels it boots with now... - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] N900: add device tree
On Mon, Jul 01, 2013 at 11:17:54PM +0200, Pavel Machek wrote: This adds device tree with neccessary support to boot with functional video (on both emulator and real N900 device). Is this really correct? You have commented out the USB, so there is no way for a developer to interact with the device. Some minor issue too: +/* + * Copyright (C) 2013 Pavel Machek pa...@ucw.cz + * Copyright 2013 Aaro Koskinen aaro.koski...@iki.fi + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 (or later) as + * published by the Free Software Foundation. Should be just GPLv2. A. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.10-rc7
On Thu, 4 Jul 2013, Paul Walmsley wrote: So that's good, will switch to am335x-bone.dtb for the testing restate jobs to be run for BeagleBone-white, and let's see what previous kernels it boots with now... Sorry, this was unclear. To rephrase, I will add BeagleBone-black boot retest runs, using am335x-bone.dtb, to the testing restate jobs that were planned for BeagleBone-white. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP baseline test results for v3.10-rc7
On Thu, Jul 04, 2013 at 05:11:33PM +, Paul Walmsley wrote: Hi On Mon, 1 Jul 2013, Felipe Balbi wrote: On Mon, Jul 01, 2013 at 07:48:50PM +, Paul Walmsley wrote: Boot to userspace: FAIL ( 2/12): 37xxevm, am335xbonelt quoting part of [1] | U-Boot# tftp 0x8200 am335x-boneblack.dtb | link up on port 0, speed 100, full duplex | Using cpsw device | TFTP from server 192.168.57.1; our IP address is 192.168.57.138 | Filename 'am335x-boneblack.dtb'. Where are you taking am335x-boneblack.dtb from ? It's not in mainline v3.10-rc7 kernel: As mentioned in my earlier reply: http://www.spinics.net/lists/arm-kernel/msg255055.html my earlier test boots were with the am335x-boneblack.dtb from the ti-linux-3.8.y tree from Vaibhav's github, since that was the only DTB that I was able to get any kernel to boot with. The am33xx_only/appended DTB issues don't apply to this board since it's booted with detached DTB and omap2plus_defconfig. Anyway, just retried it with the mainline am335x-bone.dtb file with v3.10, and the board comes up now. So that's good, will switch to am335x-bone.dtb for the testing restate jobs to be run for BeagleBone-white, and let's see what previous kernels it boots with now... alright -- balbi signature.asc Description: Digital signature
Re: OMAP baseline test results for v3.10-rc6
On Wed, 3 Jul 2013, Paul Walmsley wrote: As far as Lokesh's patch goes: it doesn't make sense to me to remove a file during 'make clean' that the build process doesn't create. So while I understand the motivation for the patch, and don't mind if upstream takes it, I personally wouldn't care to ack it. Incidentally, if there's any patch that would improve the current situation with appended DTBs by going upstream, it would be a patch like Grant's HACK patch to add appended DTB building into the kernel build system. Maybe folks can push to something similar to that one upstream? - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] N900: add device tree
Hi! This adds device tree with neccessary support to boot with functional video (on both emulator and real N900 device). Is this really correct? You have commented out the USB, so there is no way for a developer to interact with the device. Well... I do not have USB SDcard set up, so my testing was does it show failed to mount root message on screen. Now, if I do quick test of enabling it on 3.9, I get: DTC arch/arm/boot/dts/omap3-n900.dtb Error: arch/arm/boot/dts/omap3-n900.dts:92.2-3 label or path, 'usb_otg_hs', not found FATAL ERROR: Syntax error parsing input tree make[1]: *** [arch/arm/boot/dts/omap3-n900.dtb] Error 1 make: *** [dtbs] Error 2 . If you could test the patches with the USB support uncommented, that would be very good... Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] N900: add device tree
Hi, On Thu, Jul 04, 2013 at 10:21:45PM +0200, Pavel Machek wrote: This adds device tree with neccessary support to boot with functional video (on both emulator and real N900 device). Is this really correct? You have commented out the USB, so there is no way for a developer to interact with the device. Well... I do not have USB SDcard set up, so my testing was does it show failed to mount root message on screen. Now, if I do quick test of enabling it on 3.9, I get: DTC arch/arm/boot/dts/omap3-n900.dtb Error: arch/arm/boot/dts/omap3-n900.dts:92.2-3 label or path, 'usb_otg_hs', not found FATAL ERROR: Syntax error parsing input tree make[1]: *** [arch/arm/boot/dts/omap3-n900.dtb] Error 1 make: *** [dtbs] Error 2 You need 3.10. It was added in ad871c10b55654910ba97af00a00e65725da5e40 (ARM: dts: OMAP: Add usb_otg and glue data to OMAP3+ boards). 3.9 is very old. :-) If you could test the patches with the USB support uncommented, that would be very good... I can do that, but not before next week. A. -- 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/4] mtd:nand:omap2: clean-up of supported ECC schemes
On 7/3/2013 11:34 PM, Gupta, Pekon wrote:
On Wednesday 03 July 2013, Artem Bityutskiy wrote:
On Wed, 2013-07-03 at 13:16 +, Gupta, Pekon wrote:
[Pekon]: Yes, I'm not seeing these build issues, as I'm cleanly
returning from probe with pr_err(), if the required libraries
(/lib/bch.c)
are not build-in the system.
---
[Patch v4 1/4]: mtd:nand:omap2: clean-up BCHx_HW and BCHx_SW
ECC..
@@static int omap_nand_probe(struct platform_device *pdev)
+default:
+pr_err(selected ECC scheme not supported or not
enabled\n);
+err = -EINVAL;
+goto out_release_mem_region;
+}
---
However, if you are still seeing this, could you please send me your
config?
I compile tested your patches too, and did not see any issues with my
omap2_defconfig.
To clarify: I'm getting this error with randconfig on today's linux-next.
I think it only happens with MTD_NAND_ECC_BCH enabled, which is not
the default in omap2_defconfig.
Arnd
Hi Arnd, Artem, Stephen,
I see the issue in linux-next/master tree..
linux-next/master has only the first [Patch v4 1/4] from the series.
Other patches [Patch v4 2/4.. 4/4] of this series were dropped,
as 'Olof Johansson' had some apprehensions about DT bindings.
http://permalink.gmane.org/gmane.linux.ports.arm.kernel/249662
As these patches are inter-dependent, so please drop the whole series
including the commit below.
fb1585b [Patch v4 1/4] mtd: nand: omap2: clean-up BCHx_HW and
BCHx_SW
I'm awaiting feedbacks from 'Olof Johansson' or other DT maintainers,
once approved, I'll resend the whole series.
[PATCH v4 2/4] ARM: OMAP2+: cleaned-up DT support had the
declarations which were required for above build errors.
---
include/linux/platform_data/mtd-nand-omap2.h
enum omap_ecc {
+ /* 4-bit ECC calculation by GPMC, Error detection by Software */
+ OMAP_ECC_BCH4_CODE_HW_DETECTION_SW,
...
+ /* 8-bit ECC calculation by GPMC, Error detection by Software */
+ OMAP_ECC_BCH8_CODE_HW_DETECTION_SW
---
But patches should not have inter dependency for compilation. It will affect
the bisect process.
[Pekon]: They don't, If you read through the email, this issue was hit
with randconfig, and not with omap2plus_defconfig. So you would not see
build issue if you are bisecting using correct config (omap2plus_defconfig).
Also if I merge all the relevant changes in single patch, then if would
become difficult for review, and it would be conflict your earlier feedback
of breaking the patch sets.
However, I leave it to Arnd and Artem if they want me to re-shuffle
changes and re-submit.
with regards, pekon
Re: [RFC 0/4] Cleanup PRM and CM regbit headers
On Thursday 04 July 2013 10:14 PM, Paul Walmsley wrote: You mentioned that these patches were generated with some kind of awk/grep scripting. Can you integrate that in an automated way into the autogeneration flow? If the answer is yes, then keep the header. If the answer is no, then the header should be dropped. Benoît, maybe you have an opinion too? Ok, I'll try and integrate those scripts so all this can be done in an automated way even for newer SoCs. As far as whether this should go in -rcX or not, my view is that, as a matter of policy, large changes like this should wait until v3.12. Now, having written that, I also was under the impression that the OMAP5 changes weren't going to be sent upstream unless the total diffstat would be balanced to roughly zero or negative lines. As far as I know, that didn't happen. So I guess, v3.11-rc it is... kernel development by diffstat :-( I don't mind these going in -rcX or 3.12, either way is fine. Finally, please repost the whole series once you're done with your changes, as a non-RFC, along with your pull request (if you plan to send one). I guess I should be the one to take these, since I wound up taking the OMAP5 addition... :) I thought so too that you should be the one sending the pull. I will post these out as non-RFC after I do a clean integration into the autogen scripts, and then you can take a call on sending the pull for either -rcX or 3.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: OMAP baseline test results for v3.10-rc6
On Thursday 04 July 2013 11:42 PM, Paul Walmsley wrote: On Wed, 3 Jul 2013, Paul Walmsley wrote: As far as Lokesh's patch goes: it doesn't make sense to me to remove a file during 'make clean' that the build process doesn't create. So while I understand the motivation for the patch, and don't mind if upstream takes it, I personally wouldn't care to ack it. Incidentally, if there's any patch that would improve the current situation with appended DTBs by going upstream, it would be a patch like Grant's HACK patch to add appended DTB building into the kernel build system. Maybe folks can push to something similar to that one upstream? Grant already made it clear when he posted that patch that neither that nor anything similar would be taken up mainline because the appended dtb was only meant for folks stuck with legacy bootloaders and have no way to upgrade. Anyone who uses a bootloader capable of passing the dtb should *not* use the appended dtb way. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
