[RFC 0/5] EDMA: Support to DMA scatter-lists with any no. of entries
Re: on-going discussion at [1], I've added support to EDMA driver to be able to accept scatter gather lists of arbitrary length, but still make use of only a certain MAX number of slots. Thus free-ing up the rest of the slots to other slave users. With this there is no need for slave drivers to query the EDMA driver how much is the MAX. It can send SG lists of any number of entries to DMA. Tested with various number of MAX slots , even just 1. In the case where it is 1, only 1-slot is used to transmit an entire set of scatter list. If only 1 slot is used for a channel, there is a performance impact, but it works. A DMA resources vs Performance tradeoff. [1] http://marc.info/?l=linux-omapm=137416733628831w=2 Joel Fernandes (5): dma: edma: Setup parameters to DMA MAX_SG_NR at a time dma: edma: Write out and handle MAX_SG_NR at a given time ARM: edma: Add function to manually trigger an EDMA channel dma: edma: Find missed events and issue them DMA: EDMA: Leave linked to Null slot instead of DUMMY slot arch/arm/common/edma.c | 21 +++ drivers/dma/edma.c | 113 ++-- include/linux/platform_data/edma.h |2 + 3 files changed, 104 insertions(+), 32 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC 5/5] DMA: EDMA: Leave linked to Null slot instead of DUMMY slot
Dummy slot has been used as a way for missed-events not to be reported as missing. This has been particularly troublesome for cases where we might want to temporarily pause all incoming events. For EDMA DMAC, there is no way to do any such pausing of events as the occurence of the next event is not software controlled. Using edma_pause in IRQ handlers doesn't help as by then the event in concern from the slave is already missed. Linking a dummy slot, is seen to absorb these events which we didn't want to miss. So we don't link to dummy, but instead leave it linked to NULL set, allow an error condition and detect the channel that missed it. Signed-off-by: Joel Fernandes jo...@ti.com --- drivers/dma/edma.c |3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c index b0b5bcd..e9f1f27 100644 --- a/drivers/dma/edma.c +++ b/drivers/dma/edma.c @@ -160,9 +160,6 @@ static void edma_execute(struct edma_chan *echan) /* Link to the previous slot if not the last set */ if (i != (total_process - 1)) edma_link(echan-slot[i], echan-slot[i+1]); - /* Final pset links to the dummy pset */ - else - edma_link(echan-slot[i], echan-ecc-dummy_slot); } edesc-total_processed += total_process; -- 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
[RFC 2/5] dma: edma: Write out and handle MAX_SG_NR at a given time
Process SG-elements in batches of MAX_SG_NR if they are greater
than MAX_SG_NR. Due to this, at any given time only those many
slots will be used in the given channel no matter how long the
scatter list is. We keep track of how much has been written
inorder to process the next batch of elements in the scatter-list
and detect completion.
For such intermediate transfer completions (one batch of MAX_SG_NR),
make use of pause and resume functions instead of start and stop
when such intermediate transfer is in progress or completed as we
donot want to clear any pending events.
Signed-off-by: Joel Fernandes jo...@ti.com
---
drivers/dma/edma.c | 79 +++-
1 file changed, 54 insertions(+), 25 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 9b9954e..0e7ed79 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -56,6 +56,7 @@ struct edma_desc {
struct list_headnode;
int absync;
int pset_nr;
+ int total_processed;
struct edmacc_param pset[0];
};
@@ -105,22 +106,36 @@ static void edma_desc_free(struct virt_dma_desc *vdesc)
/* Dispatch a queued descriptor to the controller (caller holds lock) */
static void edma_execute(struct edma_chan *echan)
{
- struct virt_dma_desc *vdesc = vchan_next_desc(echan-vchan);
+ struct virt_dma_desc *vdesc;
struct edma_desc *edesc;
- int i;
+ struct device *dev = echan-vchan.chan.device-dev;
- if (!vdesc) {
- echan-edesc = NULL;
- return;
+ int i, j, total_left, total_process;
+
+ /* If either we processed all psets or we're still not started */
+ if (!echan-edesc ||
+ echan-edesc-pset_nr == echan-edesc-total_processed) {
+ /* Get next vdesc */
+ vdesc = vchan_next_desc(echan-vchan);
+ if (!vdesc) {
+ echan-edesc = NULL;
+ return;
+ }
+ list_del(vdesc-node);
+ echan-edesc = to_edma_desc(vdesc-tx);
}
- list_del(vdesc-node);
+ edesc = echan-edesc;
+
+ /* Find out how many left */
+ total_left = edesc-pset_nr - edesc-total_processed;
+ total_process = total_left MAX_NR_SG ? MAX_NR_SG : total_left;
- echan-edesc = edesc = to_edma_desc(vdesc-tx);
/* Write descriptor PaRAM set(s) */
- for (i = 0; i edesc-pset_nr; i++) {
- edma_write_slot(echan-slot[i], edesc-pset[i]);
+ for (i = 0; i total_process; i++) {
+ j = i + edesc-total_processed;
+ edma_write_slot(echan-slot[i], edesc-pset[j]);
dev_dbg(echan-vchan.chan.device-dev,
\n pset[%d]:\n
chnum\t%d\n
@@ -133,24 +148,31 @@ static void edma_execute(struct edma_chan *echan)
bidx\t%08x\n
cidx\t%08x\n
lkrld\t%08x\n,
- i, echan-ch_num, echan-slot[i],
- edesc-pset[i].opt,
- edesc-pset[i].src,
- edesc-pset[i].dst,
- edesc-pset[i].a_b_cnt,
- edesc-pset[i].ccnt,
- edesc-pset[i].src_dst_bidx,
- edesc-pset[i].src_dst_cidx,
- edesc-pset[i].link_bcntrld);
+ j, echan-ch_num, echan-slot[i],
+ edesc-pset[j].opt,
+ edesc-pset[j].src,
+ edesc-pset[j].dst,
+ edesc-pset[j].a_b_cnt,
+ edesc-pset[j].ccnt,
+ edesc-pset[j].src_dst_bidx,
+ edesc-pset[j].src_dst_cidx,
+ edesc-pset[j].link_bcntrld);
/* Link to the previous slot if not the last set */
- if (i != (edesc-pset_nr - 1))
+ if (i != (total_process - 1))
edma_link(echan-slot[i], echan-slot[i+1]);
/* Final pset links to the dummy pset */
else
edma_link(echan-slot[i], echan-ecc-dummy_slot);
}
- edma_start(echan-ch_num);
+ edesc-total_processed += total_process;
+
+ edma_resume(echan-ch_num);
+
+ if (edesc-total_processed = MAX_NR_SG) {
+ dev_dbg(dev, first transfer starting %d\n, echan-ch_num);
+ edma_start(echan-ch_num);
+ }
}
static int edma_terminate_all(struct edma_chan *echan)
@@ -366,19 +388,26 @@ static void edma_callback(unsigned ch_num, u16 ch_status,
void *data)
struct edma_desc *edesc;
unsigned long flags;
- /* Stop the channel */
- edma_stop(echan-ch_num);
+ /* Pause the channel
[RFC 4/5] dma: edma: Find missed events and issue them
In an effort to move to using Scatter gather lists of any size with
EDMA as discussed at [1] instead of placing limitations on the driver,
we work through the limitations of the EDMAC hardware to find missed
events and issue them.
The sequence of events that require this are:
For the scenario where MAX slots for an EDMA channel is 3:
SG1 - SG2 - SG3 - SG4 - SG5 - SG6 - Null
The above SG list will have to be DMA'd in 2 sets:
(1) SG1 - SG2 - SG3 - Null
(2) SG4 - SG5 - SG6 - Null
After (1) is succesfully transferred, the events from the MMC controller
donot stop coming and are missed by the time we have setup the transfer
for (2). So here, we catch the events missed as an error condition and
issue them manually.
[1] http://marc.info/?l=linux-omapm=137416733628831w=2
Signed-off-by: Joel Fernandes jo...@ti.com
---
drivers/dma/edma.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 0e7ed79..b0b5bcd 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -414,7 +414,15 @@ static void edma_callback(unsigned ch_num, u16 ch_status,
void *data)
break;
case DMA_CC_ERROR:
- dev_dbg(dev, transfer error on channel %d\n, ch_num);
+ if (echan-edesc) {
+ dev_dbg(dev, Missed event on %d, retrying\n,
+ ch_num);
+ edma_clean_channel(echan-ch_num);
+ edma_stop(echan-ch_num);
+ edma_start(echan-ch_num);
+ edma_manual_trigger(echan-ch_num);
+ }
+ dev_dbg(dev, handled error on channel %d\n, ch_num);
break;
default:
break;
--
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
[RFC 1/5] dma: edma: Setup parameters to DMA MAX_SG_NR at a time
Changes are made here for configuring existing parameters to support
DMA'ing them out in batches as needed.
Also allocate as many as slots as needed by the SG list, but not more
than MAX_SG_NR. Then these slots will be reused accordingly.
For ex, if MAX_SG_NR=10, and number of SG entries is 40, still only
10 slots will be allocated to DMA the entire SG list of size 40.
Also enable TC interrupts for slots that are a last in a current
iteration, or that fall on a MAX_SG_NR boundary.
Signed-off-by: Joel Fernandes jo...@ti.com
---
drivers/dma/edma.c | 21 ++---
1 file changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 083ecff..9b9954e 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -223,9 +223,11 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
enum dma_slave_buswidth dev_width;
u32 burst;
struct scatterlist *sg;
- int i;
+
int acnt, bcnt, ccnt, src, dst, cidx;
int src_bidx, dst_bidx, src_cidx, dst_cidx;
+ int i, ret;
+ int num_slots_needed;
if (unlikely(!echan || !sgl || !sg_len))
return NULL;
@@ -257,8 +259,11 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
edesc-pset_nr = sg_len;
- for_each_sg(sgl, sg, sg_len, i) {
- /* Allocate a PaRAM slot, if needed */
+ /* Allocate a PaRAM slot, if needed */
+
+ num_slots_needed = sg_len MAX_NR_SG ? MAX_NR_SG : sg_len;
+
+ for (i = 0; i num_slots_needed; i++) {
if (echan-slot[i] 0) {
echan-slot[i] =
edma_alloc_slot(EDMA_CTLR(echan-ch_num),
@@ -268,6 +273,10 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
return NULL;
}
}
+ }
+
+ /* Configure PaRAM sets for each SG */
+ for_each_sg(sgl, sg, sg_len, i) {
acnt = dev_width;
@@ -325,6 +334,12 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
/* Configure A or AB synchronized transfers */
if (edesc-absync)
edesc-pset[i].opt |= SYNCDIM;
+
+ /* If this is the last in a current SG set of transactions,
+ enable interrupts so that next set is processed */
+ if (!((i+1) % MAX_NR_SG))
+ edesc-pset[i].opt |= TCINTEN;
+
/* If this is the last set, enable completion interrupt flag */
if (i == sg_len - 1)
edesc-pset[i].opt |= TCINTEN;
--
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
[RFC 3/5] ARM: edma: Add function to manually trigger an EDMA channel
Manual trigger for events missed as a result of splitting a
scatter gather list and DMA'ing it in batches. Add a helper
function to trigger a channel incase any such events are missed.
Signed-off-by: Joel Fernandes jo...@ti.com
---
arch/arm/common/edma.c | 21 +
include/linux/platform_data/edma.h |2 ++
2 files changed, 23 insertions(+)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index 3567ba1..205f5da 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -1236,6 +1236,27 @@ void edma_resume(unsigned channel)
}
EXPORT_SYMBOL(edma_resume);
+int edma_manual_trigger(unsigned channel)
+{
+ unsigned ctlr;
+ int j;
+ unsigned int mask;
+
+ ctlr = EDMA_CTLR(channel);
+ channel = EDMA_CHAN_SLOT(channel);
+ mask = BIT(channel 0x1f);
+
+ j = channel 5;
+
+ /* EDMA channels without event association */
+ edma_shadow0_write_array(ctlr, SH_ESR, j, mask);
+
+ pr_debug(EDMA: ESR%d %08x\n, j,
+ edma_shadow0_read_array(ctlr, SH_ESR, j));
+ return 0;
+}
+EXPORT_SYMBOL(edma_manual_trigger);
+
/**
* edma_start - start dma on a channel
* @channel: channel being activated
diff --git a/include/linux/platform_data/edma.h
b/include/linux/platform_data/edma.h
index 57300fd..0e11eca 100644
--- a/include/linux/platform_data/edma.h
+++ b/include/linux/platform_data/edma.h
@@ -180,4 +180,6 @@ struct edma_soc_info {
const s16 (*xbar_chans)[2];
};
+int edma_manual_trigger(unsigned);
+
#endif
--
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
Changes in OMAP baseline testing for v3.11-rc1 onwards
Hi, Unfortunately I'm no longer able to manually track regressions and posted solutions (if any). This process consumes more time and energy than I'm able to invest now. So, starting with v3.11-rc1, the summary reports will only report the outcome of automated validation scripts. Any comments and testbed bug reports continue to be welcome, - 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
OMAP baseline test results for v3.11-rc1
Here are some basic OMAP test results for Linux v3.11-rc1. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.11-rc1/20130721020309/ Test summary Build: uImage: Pass (14/14): n800_multi_omap2xxx, n800_only_a, omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only, omap2plus_defconfig, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, rmk_omap3430_ldp_allnoconfig, rmk_omap3430_ldp_oldconfig, rmk_omap4430_sdp_allnoconfig Build: uImage+dtb: Pass ( 3/ 3): am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es Build: zImage: Pass ( 1/ 1): omap2plus_defconfig Boot to userspace: FAIL ( 5/ 11): 2430sdp, 3530es3beagle, 3730beaglexm, 5912osk, am335xbonelt Pass ( 6/ 11): 3517evm, 37xxevm, 4430es2panda, 4460pandaes, am335xbone, cmt3517 PM: chip retention via suspend: FAIL ( 4/ 6): 2430sdp, 3530es3beagle, 3730beaglexm, 4430es2panda Pass ( 2/ 6): 37xxevm, 4460pandaes PM: chip retention via dynamic idle: FAIL ( 5/ 6): 2430sdp, 3530es3beagle, 3730beaglexm, 4430es2panda, 4460pandaes Pass ( 1/ 6): 37xxevm PM: chip off except CORE via suspend: FAIL ( 1/ 1): 3730beaglexm PM: chip off except CORE via dynamic idle: FAIL ( 1/ 1): 3730beaglexm PM: chip off via suspend: FAIL ( 3/ 4): 3530es3beagle, 4430es2panda, 4460pandaes Pass ( 1/ 4): 37xxevm PM: chip off via dynamic idle: FAIL ( 3/ 4): 3530es3beagle, 4430es2panda, 4460pandaes Pass ( 1/ 4): 37xxevm vmlinux object size (delta in bytes from test_v3.10 (8bb495e3f02401ee6f76d1b1d77f3ac9f079e376)): text data bsstotal kernel +105416+2632+2000 +110048 am33xx_only +42013+1728 +960 +44701 n800_multi_omap2xxx +41993+1592 +960 +44545 n800_only_a +45499 +832 +472 +46803 omap1_defconfig +50118+2584 +472 +53174 omap1_defconfig_1510innovator_only +53938+2648 +440 +57026 omap1_defconfig_5912osk_only +159173-2456+1680 +158397 omap2plus_defconfig +156519+8608+2752 +167879 omap2plus_defconfig_2430sdp_only +144258-4400+1680 +141538 omap2plus_defconfig_cpupm +155750-2800+1744 +154694 omap2plus_defconfig_no_pm +155973 -27688+1936 +130221 omap2plus_defconfig_omap2_4_only +103989 -55072+1616 +50533 omap2plus_defconfig_omap3_4_only -30840 -110588 -736 -142164 rmk_omap3430_ldp_allnoconfig +41080 -28816+3988 +16252 rmk_omap3430_ldp_oldconfig -60468 -176540 +560 -236448 rmk_omap4430_sdp_allnoconfig Boot-time memory difference (delta in bytes from test_v3.10 (8bb495e3f02401ee6f76d1b1d77f3ac9f079e376)) avail rsrvd high freed board kconfig -44k44k .-4k 2420n800 n800_only_a -98412k -32660k . -392k 2430sdpomap2plus_defconfig -152k -872k . -12k 3517evmomap2plus_defconfig -152k -872k . -12k 3530es3beagle omap2plus_defconfig -152k -872k . -12k 3730beaglexm omap2plus_defconfig -216k -808k . -12k 4430es2panda omap2plus_defconfig -204k -820k . -12k 4460pandaesomap2plus_defconfig -48k48k . . 5912oskomap1_defconfig -116k 116k . 4k am335xbone am33xx_only -152k -872k . -12k am335xbonelt am33xx_only OMAP4 platforms have been switched to DT boots, since board file-based booting was deprecated for OMAP4 after v3.10. -- 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/15] drivers: phy: add generic PHY framework
On Sat, Jul 20, 2013 at 07:59:10PM -0700, Greg KH wrote: On Sat, Jul 20, 2013 at 10:32:26PM -0400, Alan Stern wrote: On Sat, 20 Jul 2013, Greg KH wrote: That should be passed using platform data. Ick, don't pass strings around, pass pointers. If you have platform data you can get to, then put the pointer there, don't use a name. I don't think I understood you here :-s We wont have phy pointer when we create the device for the controller no?(it'll be done in board file). Probably I'm missing something. Why will you not have that pointer? You can't rely on the name as the device id will not match up, so you should be able to rely on the pointer being in the structure that the board sets up, right? Don't use names, especially as ids can, and will, change, that is going to cause big problems. Use pointers, this is C, we are supposed to be doing that :) Kishon, I think what Greg means is this: The name you are using must be stored somewhere in a data structure constructed by the board file, right? Or at least, associated with some data structure somehow. Otherwise the platform code wouldn't know which PHY hardware corresponded to a particular name. Greg's suggestion is that you store the address of that data structure in the platform data instead of storing the name string. Have the consumer pass the data structure's address when it calls phy_create, instead of passing the name. Then you don't have to worry about two PHYs accidentally ending up with the same name or any other similar problems. Close, but the issue is that whatever returns from phy_create() should then be used, no need to call any find functions, as you can just use the pointer that phy_create() returns. Much like all other class api functions in the kernel work. I think the problem here is to connect two from the bus structure completely independent devices. Several frameworks (ASoC, soc-camera) had this problem and this wasn't solved until the advent of devicetrees and their phandles. phy_create might be called from the probe function of some i2c device (the phy device) and the resulting pointer is then needed in some other platform devices (the user of the phy) probe function. The best solution we have right now is implemented in the clk framework which uses a string matching of the device names in clk_get() (at least in the non-dt case). 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 01/15] drivers: phy: add generic PHY framework
Hi,
On Saturday 20 of July 2013 19:59:10 Greg KH wrote:
On Sat, Jul 20, 2013 at 10:32:26PM -0400, Alan Stern wrote:
On Sat, 20 Jul 2013, Greg KH wrote:
That should be passed using platform data.
Ick, don't pass strings around, pass pointers. If you have
platform
data you can get to, then put the pointer there, don't use a
name.
I don't think I understood you here :-s We wont have phy pointer
when we create the device for the controller no?(it'll be done in
board file). Probably I'm missing something.
Why will you not have that pointer? You can't rely on the name as
the device id will not match up, so you should be able to rely on
the pointer being in the structure that the board sets up, right?
Don't use names, especially as ids can, and will, change, that is
going
to cause big problems. Use pointers, this is C, we are supposed to
be
doing that :)
Kishon, I think what Greg means is this: The name you are using must
be stored somewhere in a data structure constructed by the board file,
right? Or at least, associated with some data structure somehow.
Otherwise the platform code wouldn't know which PHY hardware
corresponded to a particular name.
Greg's suggestion is that you store the address of that data structure
in the platform data instead of storing the name string. Have the
consumer pass the data structure's address when it calls phy_create,
instead of passing the name. Then you don't have to worry about two
PHYs accidentally ending up with the same name or any other similar
problems.
Close, but the issue is that whatever returns from phy_create() should
then be used, no need to call any find functions, as you can just use
the pointer that phy_create() returns. Much like all other class api
functions in the kernel work.
I think there is a confusion here about who registers the PHYs.
All platform code does is registering a platform/i2c/whatever device,
which causes a driver (located in drivers/phy/) to be instantiated. Such
drivers call phy_create(), usually in their probe() callbacks, so
platform_code has no way (and should have no way, for the sake of
layering) to get what phy_create() returns.
IMHO we need a lookup method for PHYs, just like for clocks, regulators,
PWMs or even i2c busses because there are complex cases when passing just
a name using platform data will not work. I would second what Stephen said
[1] and define a structure doing things in a DT-like way.
Example;
[platform code]
static const struct phy_lookup my_phy_lookup[] = {
PHY_LOOKUP(s3c-hsotg.0, otg, samsung-usbphy.1, phy.2),
/* etc... */
};
static void my_machine_init(void)
{
/* ... */
phy_register_lookup(my_phy_lookup, ARRAY_SIZE(my_phy_lookup));
/* ... */
}
/* Notice nothing stuffed in platform data. */
[provider code - samsung-usbphy driver]
static int samsung_usbphy_probe(...)
{
/* ... */
for (i = 0; i PHY_COUNT; ++i) {
usbphy-phy[i].name = phy;
usbphy-phy[i].id = i;
/* ... */
ret = phy_create(usbphy-phy);
/* err handling */
}
/* ... */
}
[consumer code - s3c-hsotg driver]
static int s3c_hsotg_probe(...)
{
/* ... */
phy = phy_get(pdev-dev, otg);
/* ... */
}
[1] http://thread.gmane.org/gmane.linux.ports.arm.kernel/252813
Best regards,
Tomasz
--
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/15] drivers: phy: add generic PHY framework
Hi,
On Sunday 21 July 2013 04:01 PM, Tomasz Figa wrote:
Hi,
On Saturday 20 of July 2013 19:59:10 Greg KH wrote:
On Sat, Jul 20, 2013 at 10:32:26PM -0400, Alan Stern wrote:
On Sat, 20 Jul 2013, Greg KH wrote:
That should be passed using platform data.
Ick, don't pass strings around, pass pointers. If you have
platform
data you can get to, then put the pointer there, don't use a
name.
I don't think I understood you here :-s We wont have phy pointer
when we create the device for the controller no?(it'll be done in
board file). Probably I'm missing something.
Why will you not have that pointer? You can't rely on the name as
the device id will not match up, so you should be able to rely on
the pointer being in the structure that the board sets up, right?
Don't use names, especially as ids can, and will, change, that is
going
to cause big problems. Use pointers, this is C, we are supposed to
be
doing that :)
Kishon, I think what Greg means is this: The name you are using must
be stored somewhere in a data structure constructed by the board file,
right? Or at least, associated with some data structure somehow.
Otherwise the platform code wouldn't know which PHY hardware
corresponded to a particular name.
Greg's suggestion is that you store the address of that data structure
in the platform data instead of storing the name string. Have the
consumer pass the data structure's address when it calls phy_create,
instead of passing the name. Then you don't have to worry about two
PHYs accidentally ending up with the same name or any other similar
problems.
Close, but the issue is that whatever returns from phy_create() should
then be used, no need to call any find functions, as you can just use
the pointer that phy_create() returns. Much like all other class api
functions in the kernel work.
I think there is a confusion here about who registers the PHYs.
All platform code does is registering a platform/i2c/whatever device,
which causes a driver (located in drivers/phy/) to be instantiated. Such
drivers call phy_create(), usually in their probe() callbacks, so
platform_code has no way (and should have no way, for the sake of
layering) to get what phy_create() returns.
right.
IMHO we need a lookup method for PHYs, just like for clocks, regulators,
PWMs or even i2c busses because there are complex cases when passing just
a name using platform data will not work. I would second what Stephen said
[1] and define a structure doing things in a DT-like way.
Example;
[platform code]
static const struct phy_lookup my_phy_lookup[] = {
PHY_LOOKUP(s3c-hsotg.0, otg, samsung-usbphy.1, phy.2),
The only problem here is that if *PLATFORM_DEVID_AUTO* is used while
creating the device, the ids in the device name would change and
PHY_LOOKUP wont be useful.
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: Need help for DT GPIO probing
On Sun, Jul 21, 2013 at 6:54 AM, Javier Martinez Canillas martinez.jav...@gmail.com wrote: Linus, are you still planing to send this patches as fixes for the v3.11 -rc cycle or did you decide to wait for v3.12? It will go into the v3.11 RC:s. I've just been slow due to the current heatwave over northern Europe... Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Sunday 21 of July 2013 16:37:33 Kishon Vijay Abraham I wrote:
Hi,
On Sunday 21 July 2013 04:01 PM, Tomasz Figa wrote:
Hi,
On Saturday 20 of July 2013 19:59:10 Greg KH wrote:
On Sat, Jul 20, 2013 at 10:32:26PM -0400, Alan Stern wrote:
On Sat, 20 Jul 2013, Greg KH wrote:
That should be passed using platform data.
Ick, don't pass strings around, pass pointers. If you have
platform
data you can get to, then put the pointer there, don't use a
name.
I don't think I understood you here :-s We wont have phy pointer
when we create the device for the controller no?(it'll be done in
board file). Probably I'm missing something.
Why will you not have that pointer? You can't rely on the name
as
the device id will not match up, so you should be able to rely on
the pointer being in the structure that the board sets up, right?
Don't use names, especially as ids can, and will, change, that is
going
to cause big problems. Use pointers, this is C, we are supposed to
be
doing that :)
Kishon, I think what Greg means is this: The name you are using
must
be stored somewhere in a data structure constructed by the board
file,
right? Or at least, associated with some data structure somehow.
Otherwise the platform code wouldn't know which PHY hardware
corresponded to a particular name.
Greg's suggestion is that you store the address of that data
structure
in the platform data instead of storing the name string. Have the
consumer pass the data structure's address when it calls phy_create,
instead of passing the name. Then you don't have to worry about two
PHYs accidentally ending up with the same name or any other similar
problems.
Close, but the issue is that whatever returns from phy_create()
should
then be used, no need to call any find functions, as you can just
use
the pointer that phy_create() returns. Much like all other class api
functions in the kernel work.
I think there is a confusion here about who registers the PHYs.
All platform code does is registering a platform/i2c/whatever device,
which causes a driver (located in drivers/phy/) to be instantiated.
Such drivers call phy_create(), usually in their probe() callbacks,
so platform_code has no way (and should have no way, for the sake of
layering) to get what phy_create() returns.
right.
IMHO we need a lookup method for PHYs, just like for clocks,
regulators, PWMs or even i2c busses because there are complex cases
when passing just a name using platform data will not work. I would
second what Stephen said [1] and define a structure doing things in a
DT-like way.
Example;
[platform code]
static const struct phy_lookup my_phy_lookup[] = {
PHY_LOOKUP(s3c-hsotg.0, otg, samsung-usbphy.1, phy.2),
The only problem here is that if *PLATFORM_DEVID_AUTO* is used while
creating the device, the ids in the device name would change and
PHY_LOOKUP wont be useful.
I don't think this is a problem. All the existing lookup methods already
use ID to identify devices (see regulators, clkdev, PWMs, i2c, ...). You
can simply add a requirement that the ID must be assigned manually,
without using PLATFORM_DEVID_AUTO to use PHY lookup.
Best regards,
Tomasz
--
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: Need help for DT GPIO probing
On Sunday, July 21, 2013, Linus Walleij wrote: On Sun, Jul 21, 2013 at 6:54 AM, Javier Martinez Canillas martinez.jav...@gmail.com wrote: Linus, are you still planing to send this patches as fixes for the v3.11 -rc cycle or did you decide to wait for v3.12? It will go into the v3.11 RC:s. Great, thanks a lot for your help! I've just been slow due to the current heatwave over northern Europe... Haha, yes weather has been even worst here in southern Europe Yours, Linus Walleij 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
Re: [PATCH] of: provide of_platform_unpopulate()
On 07/19/2013 01:14 PM, Sebastian Andrzej Siewior wrote:
So I called of_platform_populate() on a device to get each child device
probed and on rmmod and I need to reverse its doing. After a quick grep
I did what others did as well and rmmod ended in:
| Unable to handle kernel NULL pointer dereference at virtual address 0018
| PC is at release_resource+0x18/0x80
| Process rmmod (pid: 2005, stack limit = 0xedc30238)
| [c003add0] (release_resource+0x18/0x80) from [c0300e08]
(platform_device_del+0x78/0xac)
| [c0300e08] (platform_device_del+0x78/0xac) from [c0301358]
(platform_device_unregister+0xc/0x18)
The problem is that platform_device_del() releases each ressource in its
tree. This does not work on platform_devices created by OF becuase they
were never added via insert_resource(). As a consequence old-parent in
__release_resource() is NULL and we explode while accessing -child.
So I either I do something completly wrong _or_ nobody here tested the
rmmod path of their driver.
Wouldn't the correct fix be to call insert_resource somehow? The problem
I have is that while of_platform_populate is all about parsing the DT
and creating devices, the removal side has nothing to do with DT. So
this should not be in the DT code. I think the core device code should
be able to handle removal if the device creation side is done correctly.
It looks to me like of_device_add either needs to call
platform_device_add rather than device_add. I think the device name
setting in platform_device_add should be a nop. If not, a check that the
name is already set could be added.
Rob
This patch provides a common function to unregister / remove devices
which added to the system via of_platform_populate(). While this works
now on my test case I have not tested any of the driver I modify here so
feedback is greatly appreciated.
Cc: Tony Lindgren t...@atomide.com
Cc: Doug Anderson diand...@chromium.org
Cc: Vivek Gautam gautam.vi...@samsung.com
Cc: Naveen Krishna Chatradhi ch.nav...@samsung.com
Cc: Kukjin Kim kgene@samsung.com
Cc: Kishon Vijay Abraham I kis...@ti.com
Cc: Roger Quadros rog...@ti.com
Cc: George Cherian george.cher...@ti.com
Cc: Felipe Balbi ba...@ti.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/bus/omap-ocp2scp.c | 13 ++---
drivers/iio/adc/exynos_adc.c | 15 ++-
drivers/mfd/omap-usb-host.c| 9 +
drivers/of/platform.c | 22 ++
drivers/usb/dwc3/dwc3-exynos.c | 11 +--
drivers/usb/dwc3/dwc3-omap.c | 12 +---
include/linux/of_platform.h| 4
7 files changed, 33 insertions(+), 53 deletions(-)
diff --git a/drivers/bus/omap-ocp2scp.c b/drivers/bus/omap-ocp2scp.c
index 5511f98..510bb9e 100644
--- a/drivers/bus/omap-ocp2scp.c
+++ b/drivers/bus/omap-ocp2scp.c
@@ -23,15 +23,6 @@
#include linux/of.h
#include linux/of_platform.h
-static int ocp2scp_remove_devices(struct device *dev, void *c)
-{
- struct platform_device *pdev = to_platform_device(dev);
-
- platform_device_unregister(pdev);
-
- return 0;
-}
-
static int omap_ocp2scp_probe(struct platform_device *pdev)
{
int ret;
@@ -51,7 +42,7 @@ static int omap_ocp2scp_probe(struct platform_device *pdev)
return 0;
err0:
- device_for_each_child(pdev-dev, NULL, ocp2scp_remove_devices);
+ of_platform_unpopulate(pdev-dev);
return ret;
}
@@ -59,7 +50,7 @@ static int omap_ocp2scp_probe(struct platform_device *pdev)
static int omap_ocp2scp_remove(struct platform_device *pdev)
{
pm_runtime_disable(pdev-dev);
- device_for_each_child(pdev-dev, NULL, ocp2scp_remove_devices);
+ of_platform_unpopulate(pdev-dev);
return 0;
}
diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index 9809fc9..10248e1 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -216,15 +216,6 @@ static const struct iio_chan_spec
exynos_adc_iio_channels[] = {
ADC_CHANNEL(9, adc9),
};
-static int exynos_adc_remove_devices(struct device *dev, void *c)
-{
- struct platform_device *pdev = to_platform_device(dev);
-
- platform_device_unregister(pdev);
-
- return 0;
-}
-
static void exynos_adc_hw_init(struct exynos_adc *info)
{
u32 con1, con2;
@@ -357,8 +348,7 @@ static int exynos_adc_probe(struct platform_device *pdev)
return 0;
err_of_populate:
- device_for_each_child(pdev-dev, NULL,
- exynos_adc_remove_devices);
+ of_platform_unpopulate(pdev-dev);
regulator_disable(info-vdd);
clk_disable_unprepare(info-clk);
err_iio_dev:
@@ -375,8 +365,7 @@ static int exynos_adc_remove(struct platform_device *pdev)
struct iio_dev *indio_dev = platform_get_drvdata(pdev);
struct exynos_adc *info = iio_priv(indio_dev);
- device_for_each_child(pdev-dev, NULL,
-
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Sun, Jul 21, 2013 at 01:12:07PM +0200, Tomasz Figa wrote:
On Sunday 21 of July 2013 16:37:33 Kishon Vijay Abraham I wrote:
Hi,
On Sunday 21 July 2013 04:01 PM, Tomasz Figa wrote:
Hi,
On Saturday 20 of July 2013 19:59:10 Greg KH wrote:
On Sat, Jul 20, 2013 at 10:32:26PM -0400, Alan Stern wrote:
On Sat, 20 Jul 2013, Greg KH wrote:
That should be passed using platform data.
Ick, don't pass strings around, pass pointers. If you have
platform
data you can get to, then put the pointer there, don't use a
name.
I don't think I understood you here :-s We wont have phy pointer
when we create the device for the controller no?(it'll be done in
board file). Probably I'm missing something.
Why will you not have that pointer? You can't rely on the name
as
the device id will not match up, so you should be able to rely on
the pointer being in the structure that the board sets up, right?
Don't use names, especially as ids can, and will, change, that is
going
to cause big problems. Use pointers, this is C, we are supposed to
be
doing that :)
Kishon, I think what Greg means is this: The name you are using
must
be stored somewhere in a data structure constructed by the board
file,
right? Or at least, associated with some data structure somehow.
Otherwise the platform code wouldn't know which PHY hardware
corresponded to a particular name.
Greg's suggestion is that you store the address of that data
structure
in the platform data instead of storing the name string. Have the
consumer pass the data structure's address when it calls phy_create,
instead of passing the name. Then you don't have to worry about two
PHYs accidentally ending up with the same name or any other similar
problems.
Close, but the issue is that whatever returns from phy_create()
should
then be used, no need to call any find functions, as you can just
use
the pointer that phy_create() returns. Much like all other class api
functions in the kernel work.
I think there is a confusion here about who registers the PHYs.
All platform code does is registering a platform/i2c/whatever device,
which causes a driver (located in drivers/phy/) to be instantiated.
Such drivers call phy_create(), usually in their probe() callbacks,
so platform_code has no way (and should have no way, for the sake of
layering) to get what phy_create() returns.
Why not put pointers in the platform data structure that can hold these
pointers? I thought that is why we created those structures in the
first place. If not, what are they there for?
IMHO we need a lookup method for PHYs, just like for clocks,
regulators, PWMs or even i2c busses because there are complex cases
when passing just a name using platform data will not work. I would
second what Stephen said [1] and define a structure doing things in a
DT-like way.
Example;
[platform code]
static const struct phy_lookup my_phy_lookup[] = {
PHY_LOOKUP(s3c-hsotg.0, otg, samsung-usbphy.1, phy.2),
The only problem here is that if *PLATFORM_DEVID_AUTO* is used while
creating the device, the ids in the device name would change and
PHY_LOOKUP wont be useful.
I don't think this is a problem. All the existing lookup methods already
use ID to identify devices (see regulators, clkdev, PWMs, i2c, ...). You
can simply add a requirement that the ID must be assigned manually,
without using PLATFORM_DEVID_AUTO to use PHY lookup.
And I'm saying that this idea, of using a specific name and id, is
frought with fragility and will break in the future in various ways when
devices get added to systems, making these strings constantly have to be
kept up to date with different board configurations.
People, NEVER, hardcode something like an id. The fact that this
happens today with the clock code, doesn't make it right, it makes the
clock code wrong. Others have already said that this is wrong there as
well, as systems change and dynamic ids get used more and more.
Let's not repeat the same mistakes of the past just because we refuse to
learn from them...
So again, the find a phy by a string functions should be removed, the
device id should be automatically created by the phy core just to make
things unique in sysfs, and no driver code should _ever_ be reliant on
the number that is being created, and the pointer to the phy structure
should be used everywhere instead.
With those types of changes, I will consider merging this subsystem, but
without them, sorry, I will not.
thanks,
greg k-h
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/15] drivers: phy: add generic PHY framework
On Sun, Jul 21, 2013 at 12:22:48PM +0200, Sascha Hauer wrote: On Sat, Jul 20, 2013 at 07:59:10PM -0700, Greg KH wrote: On Sat, Jul 20, 2013 at 10:32:26PM -0400, Alan Stern wrote: On Sat, 20 Jul 2013, Greg KH wrote: That should be passed using platform data. Ick, don't pass strings around, pass pointers. If you have platform data you can get to, then put the pointer there, don't use a name. I don't think I understood you here :-s We wont have phy pointer when we create the device for the controller no?(it'll be done in board file). Probably I'm missing something. Why will you not have that pointer? You can't rely on the name as the device id will not match up, so you should be able to rely on the pointer being in the structure that the board sets up, right? Don't use names, especially as ids can, and will, change, that is going to cause big problems. Use pointers, this is C, we are supposed to be doing that :) Kishon, I think what Greg means is this: The name you are using must be stored somewhere in a data structure constructed by the board file, right? Or at least, associated with some data structure somehow. Otherwise the platform code wouldn't know which PHY hardware corresponded to a particular name. Greg's suggestion is that you store the address of that data structure in the platform data instead of storing the name string. Have the consumer pass the data structure's address when it calls phy_create, instead of passing the name. Then you don't have to worry about two PHYs accidentally ending up with the same name or any other similar problems. Close, but the issue is that whatever returns from phy_create() should then be used, no need to call any find functions, as you can just use the pointer that phy_create() returns. Much like all other class api functions in the kernel work. I think the problem here is to connect two from the bus structure completely independent devices. Several frameworks (ASoC, soc-camera) had this problem and this wasn't solved until the advent of devicetrees and their phandles. phy_create might be called from the probe function of some i2c device (the phy device) and the resulting pointer is then needed in some other platform devices (the user of the phy) probe function. The best solution we have right now is implemented in the clk framework which uses a string matching of the device names in clk_get() (at least in the non-dt case). I would argue that clocks are wrong here as well, as others have already pointed out. What's wrong with the platform_data structure, why can't that be used for this? Or, if not, we can always add pointers to the platform device structure, or even the main 'struct device' as well, that's what it is there for. thanks, greg k-h -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ASoC: omap-mcbsp: Support SND_SOC_DAIFMT_CBM_CFS for omap3/4
Add SND_SOC_DAIFMT_CBM_CFS support for omap3/omap4. The patch was tested on a pandaboard-es board connected to the pcm1792a codec. mcbspx_fsx must configured as output and mcbspx_clkx must be configured as input. Signed-off-by: Michael Trimarchi mich...@amarulasolutions.com --- sound/soc/omap/omap-mcbsp.c |5 + 1 file changed, 5 insertions(+) diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c index 7483efb..6c19bba 100644 --- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -433,6 +433,11 @@ static int omap_mcbsp_dai_set_dai_fmt(struct snd_soc_dai *cpu_dai, /* Sample rate generator drives the FS */ regs-srgr2 |= FSGM; break; + case SND_SOC_DAIFMT_CBM_CFS: + /* McBSP slave. FS clock as output */ + regs-srgr2 |= FSGM; + regs-pcr0 |= FSXM; + break; case SND_SOC_DAIFMT_CBM_CFM: /* McBSP slave */ break; -- 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: [PATCH 1/3] misc: Add crossbar driver
On Thu, Jul 18, 2013 at 8:25 PM, Felipe Balbi ba...@ti.com wrote: The Peripheral irq/dma requests are connected to one crossbar's input and the output of the crossbar is connected to controller's input line. On POR, there are some mappings which are done by default. Those peripherals which do not have a mapping on POR, should be configured to route its requests using the crossbar. (...) why isn't this done under pinctrl ? If all it does is mux DMA and IRQ request lines, it should be written as a pinctrl driver no ? Actually I was thinking about this at one time when designing pinctrl, what if we face the problem of arbitrary signal multiplexing? However pin control is named for what it does and also controls things like the electrical properties of pins, biasing and so on which is ill applicable here. I would rather say that the pin multiplexing portions of pin control could be rewritten to use a more generic component dealing with arbitrary line multiplexing, i.e. something under /lib and maybe then move over some generic concepts such as the function to group mapping. The same concept as found here is found in the muxes used by drivers/dma/amba-pl08x.c back-ends on ARM reference hardware which is also multiplexing DMA signals. In that case we have done platform-specific hooks and implemented this in the per-machine platform code. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] misc: Add crossbar driver
On Thu, Jul 18, 2013 at 8:56 PM, Nishanth Menon n...@ti.com wrote:
I carry forward my TI internal objection to this approach:
It is actually a very good sign of FOSS-maturity that you as a company
take unresolved architectural issues to the community. Kudos!
Lets see what happens as a result of this:
https://patchwork.kernel.org/patch/2825148/ (introducing DTS for DRA7)
uart1 to uart6 is defined. while in fact 10 uarts exist on IP block.
uart1: serial@4806a000 {
snip
+ interrupts = 0 72 0x4;
Assumes that GIC interrupt by default mapping used.
So introducing this inbetween the GIC lines and its actual device IRQ
lines inevitably means that the GIC three-cell concept is completely
ill-devised to handle this.
For routing IRQs, I think the proper solution would be to use a
cascaded struct irqchip, which in turn contains an irqdomain
translation to remux the signal onto the GIC inputs.
I.e. the interrupt-controller given to that serial would be the
crossbar irqchip, and that in turn will hog and allocate apropriate
lines from the gic to it would probably itself list *all* the IRQs
of the GIC as its IRQs.
We already have plenty of cascading irqchips such as GPIO
controller providing IRQs, just that they only multiplex on a
single GIC line instead of the whole lot.
Mock example:
intc: interrupt-controller@0 {
compatible = arm,cortex-a9-gic;
#interrupt-cells = 3;
#address-cells = 1;
interrupt-controller;
reg = ...;
};
crossbar: crossbar@0 {
compatible = ...;
interrupt-controller;
#interrupt-cells = 1;
interrupt-parent = intc;
interrupts = 0 0 IRQ_TYPE_LEVEL_HIGH,
0 1 IRQ_TYPE_LEVEL_HIGH,
0 2 IRQ_TYPE_LEVEL_HIGH,
0 n IRQ_TYPE_LEVEL_HIGH;
};
uart0: serial@0 {
compatible = ...;
interrupt-parent = crossbar;
interrupts = 1234;
};
Maybe the interrupts provided from crossbar cannot even be
specified by a number, maybe a line name need to be used
or so. I don't know the particulars.
Whether this as a whole is a good idea, I don't know,
but you would have to go about it something like this.
What happens if there is no line to mux in a certain IRQ?
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Unable to randomly boot rootfs (EXT3 or EXT4) from SD: MMC error -110 (TIMEDOUT)
Hi, I'm trying to figure out why when randomly booting our system after it = have been hard shutdown for some time (couple of minutes to couple of = days) doesn't boot with MMC error?=20 WORKAROUND: Rebooting the system most of the time remove the issue. I try couple of version of Kernel from stable 3.2.47 3.4.53 without = success. I try to change FS from EXT3 to EXT4 without success. I try multiple SD.. Any proposition of test that you think that is worth trying, I'm willing = to try. Your opinions will really be appreciated, See below for some output of my environment, http://pastebin.com/qchsr1FQ Thx, -Kevyn-Alexandre Par=E9 ps: My intention are to enable CONFIG_MMC_DEBUG? Try kernel 3.10.1? -- 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/15] drivers: phy: add generic PHY framework
On 07/21/2013 05:48 PM, Greg KH wrote: On Sun, Jul 21, 2013 at 12:22:48PM +0200, Sascha Hauer wrote: On Sat, Jul 20, 2013 at 07:59:10PM -0700, Greg KH wrote: On Sat, Jul 20, 2013 at 10:32:26PM -0400, Alan Stern wrote: On Sat, 20 Jul 2013, Greg KH wrote: That should be passed using platform data. Ick, don't pass strings around, pass pointers. If you have platform data you can get to, then put the pointer there, don't use a name. I don't think I understood you here :-s We wont have phy pointer when we create the device for the controller no?(it'll be done in board file). Probably I'm missing something. Why will you not have that pointer? You can't rely on the name as the device id will not match up, so you should be able to rely on the pointer being in the structure that the board sets up, right? Don't use names, especially as ids can, and will, change, that is going to cause big problems. Use pointers, this is C, we are supposed to be doing that :) Kishon, I think what Greg means is this: The name you are using must be stored somewhere in a data structure constructed by the board file, right? Or at least, associated with some data structure somehow. Otherwise the platform code wouldn't know which PHY hardware corresponded to a particular name. Greg's suggestion is that you store the address of that data structure in the platform data instead of storing the name string. Have the consumer pass the data structure's address when it calls phy_create, instead of passing the name. Then you don't have to worry about two PHYs accidentally ending up with the same name or any other similar problems. Close, but the issue is that whatever returns from phy_create() should then be used, no need to call any find functions, as you can just use the pointer that phy_create() returns. Much like all other class api functions in the kernel work. I think the problem here is to connect two from the bus structure completely independent devices. Several frameworks (ASoC, soc-camera) had this problem and this wasn't solved until the advent of devicetrees and their phandles. phy_create might be called from the probe function of some i2c device (the phy device) and the resulting pointer is then needed in some other platform devices (the user of the phy) probe function. The best solution we have right now is implemented in the clk framework which uses a string matching of the device names in clk_get() (at least in the non-dt case). I would argue that clocks are wrong here as well, as others have already pointed out. What's wrong with the platform_data structure, why can't that be used for this? At the point the platform data of some driver is initialized, e.g. in board setup code the PHY pointer is not known, since the PHY supplier driver has not initialized yet. Even though we wanted to pass pointer to a PHY through some notifier call, it would have been not clear which PHY user driver should match on such notifier. A single PHY supplier driver can create M PHY objects and this needs to be mapped to N PHY user drivers. This mapping needs to be defined somewhere by the system integrator. It works well with device tree, but except that there seems to be no other reliable infrastructure in the kernel to define links/dependencies between devices, since device identifiers are not known in advance in all cases. What Tomasz proposed seems currently most reasonable to me for non-dt. Or, if not, we can always add pointers to the platform device structure, or even the main 'struct device' as well, that's what it is there for. Still we would need to solve a problem which platform device structure gets which PHY pointer. -- Regards, Sylwester -- 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] ASoC: omap-mcbsp: Support SND_SOC_DAIFMT_CBM_CFS for omap3/4
On 07/21/2013 06:24 PM, Michael Trimarchi wrote: Add SND_SOC_DAIFMT_CBM_CFS support for omap3/omap4. The patch was tested on a pandaboard-es board connected to the pcm1792a codec. mcbspx_fsx must configured as output and mcbspx_clkx must be configured as input. Acked-by: Peter Ujfalusi peter.ujfal...@ti.com Signed-off-by: Michael Trimarchi mich...@amarulasolutions.com --- sound/soc/omap/omap-mcbsp.c |5 + 1 file changed, 5 insertions(+) diff --git a/sound/soc/omap/omap-mcbsp.c b/sound/soc/omap/omap-mcbsp.c index 7483efb..6c19bba 100644 --- a/sound/soc/omap/omap-mcbsp.c +++ b/sound/soc/omap/omap-mcbsp.c @@ -433,6 +433,11 @@ static int omap_mcbsp_dai_set_dai_fmt(struct snd_soc_dai *cpu_dai, /* Sample rate generator drives the FS */ regs-srgr2 |= FSGM; break; + case SND_SOC_DAIFMT_CBM_CFS: + /* McBSP slave. FS clock as output */ + regs-srgr2 |= FSGM; + regs-pcr0 |= FSXM; + break; case SND_SOC_DAIFMT_CBM_CFM: /* McBSP slave */ break; -- Péter -- 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/15] drivers: phy: add generic PHY framework
On Sun, 21 Jul 2013, Sylwester Nawrocki wrote: What's wrong with the platform_data structure, why can't that be used for this? At the point the platform data of some driver is initialized, e.g. in board setup code the PHY pointer is not known, since the PHY supplier driver has not initialized yet. Even though we wanted to pass pointer to a PHY through some notifier call, it would have been not clear which PHY user driver should match on such notifier. A single PHY supplier driver can create M PHY objects and this needs to be mapped to N PHY user drivers. This mapping needs to be defined somewhere by the system integrator. It works well with device tree, but except that there seems to be no other reliable infrastructure in the kernel to define links/dependencies between devices, since device identifiers are not known in advance in all cases. What Tomasz proposed seems currently most reasonable to me for non-dt. Or, if not, we can always add pointers to the platform device structure, or even the main 'struct device' as well, that's what it is there for. Still we would need to solve a problem which platform device structure gets which PHY pointer. Can you explain the issues in more detail? I don't fully understand the situation. Here's what I think I know: The PHY and the controller it is attached to are both physical devices. The connection between them is hardwired by the system manufacturer and cannot be changed by software. PHYs are generally described by fixed system-specific board files or by Device Tree information. Are they ever discovered dynamically? Is the same true for the controllers attached to the PHYs? If not -- if both a PHY and a controller are discovered dynamically -- how does the kernel know whether they are connected to each other? The kernel needs to know which controller is attached to which PHY. Currently this information is represented by name or ID strings embedded in platform data. The PHY's driver (the supplier) uses the platform data to construct a platform_device structure that represents the PHY. Until this is done, the controller's driver (the client) cannot use the PHY. Since there is no parent-child relation between the PHY and the controller, there is no guarantee that the PHY's driver will be ready when the controller's driver wants to use it. A deferred probe may be needed. The issue (or one of the issues) in this discussion is that Greg does not like the idea of using names or IDs to associate PHYs with controllers, because they are too prone to duplications or other errors. Pointers are more reliable. But pointers to what? Since the only data known to be available to both the PHY driver and controller driver is the platform data, the obvious answer is a pointer to platform data (either for the PHY or for the controller, or maybe both). Probably some of the details above are wrong; please indicate where I have gone astray. Also, I'm not clear about the role played by various APIs. For example, where does phy_create() fit into this picture? Alan Stern -- 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] of: provide of_platform_unpopulate()
On 07/21/2013 04:42 PM, Rob Herring wrote: Wouldn't the correct fix be to call insert_resource somehow? Yes unless there was a reason this wasn't done in the first place. The problem I have is that while of_platform_populate is all about parsing the DT and creating devices, the removal side has nothing to do with DT. So this should not be in the DT code. I think the core device code should be able to handle removal if the device creation side is done correctly. If there is no need to use the special removal function (in case we add insert_ressource) then yes. What about a pointer in of_platform_populate()'s comment referring to the removal function? It looks to me like of_device_add either needs to call platform_device_add rather than device_add. I think the device name setting in platform_device_add should be a nop. If not, a check that the name is already set could be added. It does actually the same thing as platform_device_add except the dynamic device id and the resource insert if I remember correctly. If you guys prefer the platdorm_device_add() path including insert_ressource() I can try this. Rob 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] of: provide of_platform_unpopulate()
On 07/21/2013 09:42 AM, Rob Herring wrote: On 07/19/2013 01:14 PM, Sebastian Andrzej Siewior wrote: So I called of_platform_populate() on a device to get each child device probed and on rmmod and I need to reverse its doing. After a quick grep I did what others did as well and rmmod ended in: | Unable to handle kernel NULL pointer dereference at virtual address 0018 | PC is at release_resource+0x18/0x80 | Process rmmod (pid: 2005, stack limit = 0xedc30238) | [c003add0] (release_resource+0x18/0x80) from [c0300e08] (platform_device_del+0x78/0xac) | [c0300e08] (platform_device_del+0x78/0xac) from [c0301358] (platform_device_unregister+0xc/0x18) The problem is that platform_device_del() releases each ressource in its tree. This does not work on platform_devices created by OF becuase they were never added via insert_resource(). As a consequence old-parent in __release_resource() is NULL and we explode while accessing -child. So I either I do something completly wrong _or_ nobody here tested the rmmod path of their driver. Wouldn't the correct fix be to call insert_resource somehow? The problem I have is that while of_platform_populate is all about parsing the DT and creating devices, the removal side has nothing to do with DT. So this should not be in the DT code. I think the core device code should be able to handle removal if the device creation side is done correctly. It looks to me like of_device_add either needs to call platform_device_add rather than device_add. I think the device name setting in platform_device_add should be a nop. If not, a check that the name is already set could be added. BTW, it looks like Grant has attempted this already: commit 02bbde7849e68e193cefaa1885fe0df0f03c9fcd Author: Grant Likely grant.lik...@secretlab.ca Date: Sun Feb 17 20:03:27 2013 + Revert of: use platform_device_add This reverts commit aac73f34542bc7ae4317928d2eabfeb21d247323. That commit causes two kinds of breakage; it breaks registration of AMBA devices when one of the parent nodes already contains overlapping resource regions, and it breaks calls to request_region() by device drivers in certain conditions where there are overlapping memory regions. Both of these problems can probably be fixed, but it is better to back out the commit and get a proper fix designed before trying again. Signed-off-by: Grant Likely grant.lik...@secretlab.ca Rob -- 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] of: provide of_platform_unpopulate()
On Sun, Jul 21, 2013 at 9:48 PM, Rob Herring robherri...@gmail.com wrote: On 07/21/2013 09:42 AM, Rob Herring wrote: On 07/19/2013 01:14 PM, Sebastian Andrzej Siewior wrote: So I called of_platform_populate() on a device to get each child device probed and on rmmod and I need to reverse its doing. After a quick grep I did what others did as well and rmmod ended in: | Unable to handle kernel NULL pointer dereference at virtual address 0018 | PC is at release_resource+0x18/0x80 | Process rmmod (pid: 2005, stack limit = 0xedc30238) | [c003add0] (release_resource+0x18/0x80) from [c0300e08] (platform_device_del+0x78/0xac) | [c0300e08] (platform_device_del+0x78/0xac) from [c0301358] (platform_device_unregister+0xc/0x18) The problem is that platform_device_del() releases each ressource in its tree. This does not work on platform_devices created by OF becuase they were never added via insert_resource(). As a consequence old-parent in __release_resource() is NULL and we explode while accessing -child. So I either I do something completly wrong _or_ nobody here tested the rmmod path of their driver. Wouldn't the correct fix be to call insert_resource somehow? The problem I have is that while of_platform_populate is all about parsing the DT and creating devices, the removal side has nothing to do with DT. So this should not be in the DT code. I think the core device code should be able to handle removal if the device creation side is done correctly. It looks to me like of_device_add either needs to call platform_device_add rather than device_add. I think the device name setting in platform_device_add should be a nop. If not, a check that the name is already set could be added. BTW, it looks like Grant has attempted this already: Yup, things broke badly. Unfortunately the of_platform_device and platform_device history doesn't treat resources in the same way. I would like to merge the code, but I haven't been able to figure out a clean way to do it. Looks like we do need the unpopulate function. g. -- 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] ASoC: omap-mcbsp: Support SND_SOC_DAIFMT_CBM_CFS for omap3/4
On Sun, Jul 21, 2013 at 06:24:01PM +0200, Michael Trimarchi wrote: Add SND_SOC_DAIFMT_CBM_CFS support for omap3/omap4. The patch was tested on a pandaboard-es board connected to the pcm1792a codec. mcbspx_fsx must configured as output and mcbspx_clkx must be configured as input. Applied, thanks. signature.asc Description: Digital signature
OMAP baseline test results for Linux v3.11-rc2
Here are some basic OMAP test results for Linux v3.11-rc2. Logs and other details at: http://www.pwsan.com/omap/testlogs/test_v3.11-rc2/20130721203314/ Test summary Build: uImage: Pass (14/14): n800_multi_omap2xxx, n800_only_a, omap1_defconfig, omap1_defconfig_1510innovator_only, omap1_defconfig_5912osk_only, omap2plus_defconfig, omap2plus_defconfig_2430sdp_only, omap2plus_defconfig_cpupm, omap2plus_defconfig_no_pm, omap2plus_defconfig_omap2_4_only, omap2plus_defconfig_omap3_4_only, rmk_omap3430_ldp_allnoconfig, rmk_omap3430_ldp_oldconfig, rmk_omap4430_sdp_allnoconfig Build: uImage+dtb: Pass ( 3/ 3): am33xx_only/am335x-bone, omap2plus_defconfig/omap4-panda, omap2plus_defconfig/omap4-panda-es Build: zImage: Pass ( 1/ 1): omap2plus_defconfig Boot to userspace: FAIL ( 5/11): 2430sdp, 3530es3beagle, 3730beaglexm, 5912osk, am335xbonelt Pass ( 6/11): 3517evm, 37xxevm, 4430es2panda, 4460pandaes, am335xbone, cmt3517 PM: chip retention via suspend: FAIL ( 4/ 6): 2430sdp, 3530es3beagle, 3730beaglexm, 4430es2panda Pass ( 2/ 6): 37xxevm, 4460pandaes PM: chip retention via dynamic idle: FAIL ( 5/ 6): 2430sdp, 3530es3beagle, 3730beaglexm, 4430es2panda, 4460pandaes Pass ( 1/ 6): 37xxevm PM: chip off except CORE via suspend: FAIL ( 1/ 1): 3730beaglexm PM: chip off except CORE via dynamic idle: FAIL ( 1/ 1): 3730beaglexm PM: chip off via suspend: FAIL ( 3/ 4): 3530es3beagle, 4430es2panda, 4460pandaes Pass ( 1/ 4): 37xxevm PM: chip off via dynamic idle: FAIL ( 3/ 4): 3530es3beagle, 4430es2panda, 4460pandaes Pass ( 1/ 4): 37xxevm vmlinux object size (delta in bytes from test_v3.11-rc1 (ad81f0545ef01ea651886dddac4bef6cec930092)): text data bsstotal kernel +658 +3200 +978 am33xx_only +350 +1920 +542 n800_multi_omap2xxx +318 +1920 +510 n800_only_a +490 +1920 +682 omap1_defconfig +554 +2240 +778 omap1_defconfig_1510innovator_only +490 +1920 +682 omap1_defconfig_5912osk_only +670 +3200 +990 omap2plus_defconfig +4834 +3200+5154 omap2plus_defconfig_2430sdp_only +618 +3840+1002 omap2plus_defconfig_cpupm +670 +2560 +926 omap2plus_defconfig_no_pm +670 +3200 +990 omap2plus_defconfig_omap2_4_only +670 +3200 +990 omap2plus_defconfig_omap3_4_only +336 +96 -72 +360 rmk_omap3430_ldp_allnoconfig +318 +1920 +510 rmk_omap3430_ldp_oldconfig +288 +96 -24 +360 rmk_omap4430_sdp_allnoconfig Boot-time memory difference (delta in bytes from test_v3.11-rc1 (ad81f0545ef01ea651886dddac4bef6cec930092)) avail rsrvd high freed board kconfig (no differences) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL] ARM: OMAP2+: PRCM: drop macros not currently in use
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Tony, Sorry for the delay on this - wanted to make sure it passed the local testbed before sending it upstream. The following changes since commit 3b2f64d00c46e1e4e9bd0bb9bb12619adac27a4b: Linux 3.11-rc2 (2013-07-21 12:05:29 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/pjw/omap-pending.git tags/for-v3.11-rc/omap-fixes-a for you to fetch changes up to 11dab344053f726fe17ede95aa52c1eea1258a66: ARM: OMAP5: PRM/CM: Cleanup unused header (2013-07-21 22:10:25 -0600) - This series removes the currently-unused PRCM macros from arch/arm/mach-omap2. Basic test logs are available at: http://www.pwsan.com/omap/testlogs/drop_unused_prcm_macros_v3.11-rc/20130721211401/ Once, years ago, we thought that it would be good to document the PRCM register bits in the Linux codebase. Most folks in the broader community did not have access to the same documentation, so we thought that they might be able to use these bits to fix bugs and improve the code. We were also able to autogenerate most of these macros, so it was thought that defining them in advance would reduce the risk of error, inconsistencies, and merge conflicts caused when patch sets incrementally defined them by hand. Well, nice thoughts. But the first rationale was rendered partially obsolete when TI started to release public TRM documentation PDFs at some point in the OMAP3 timeframe. (Despite their weaknesses, TI's public OMAP TRMs remain the most useful public documentation available for any ARM Linux SoC -- at least to the extent of my knowledge.) And then the current Linux development tropism towards development-by-negative-diffstat obliterated the remainder of the above two philosophies. So, for the few, the masochistic, out there who wish to continue developing TI PRCM code, I would ask that you resurrect any additionally-needed macros from these commits, rather than writing them manually. Purely for the sake of a pleasant atavism, perhaps; the way one appreciates a used bookstore, or a video rental store... And thanks to the upstream maintainers for being patient while we adjust. - Rajendra Nayak (4): ARM: OMAP2: PRM/CM: Cleanup unused header ARM: OMAP3: PRM/CM: Cleanup unused header ARM: OMAP4: PRM/CM: Cleanup unused header ARM: OMAP5: PRM/CM: Cleanup unused header arch/arm/mach-omap2/cm-regbits-24xx.h | 318 arch/arm/mach-omap2/cm-regbits-33xx.h | 749 arch/arm/mach-omap2/cm-regbits-34xx.h | 632 --- arch/arm/mach-omap2/cm-regbits-44xx.h | 1558 --- arch/arm/mach-omap2/cm-regbits-54xx.h | 1633 arch/arm/mach-omap2/omap_hwmod_54xx_data.c |1 - arch/arm/mach-omap2/powerdomains54xx_data.c |1 - arch/arm/mach-omap2/prm-regbits-24xx.h | 247 --- arch/arm/mach-omap2/prm-regbits-33xx.h | 306 --- arch/arm/mach-omap2/prm-regbits-34xx.h | 481 - arch/arm/mach-omap2/prm-regbits-44xx.h | 2226 -- arch/arm/mach-omap2/prm-regbits-54xx.h | 2701 --- 12 files changed, 10853 deletions(-) delete mode 100644 arch/arm/mach-omap2/prm-regbits-54xx.h -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJR7Lr/AAoJEMePsQ0LvSpLPCwP/1DiY3jzuSubA9N51NwmnROw 1LZS9ZMcaQ6Mr24pC03wDyQ81vSl+voY54VMyu4zvbt+qJyHkVabpXn3pGyEyzub fap7VyC/Szfx0GtuuAAhXYAPn6qwuKJ122jbgtEe5x4eEOpvY/X+ArYcwgxp3uG0 CmkJb1O5FSyY+AW3isPQPrrKUIdy98s12v0q1xdN0eTRua31D7I1TPutAD4LbWQ4 oUbFqG4hybFLlXLZvJF4BrPVMFld5gPVDFvdp2jdtH5Kcyp2bRXXv5xmKHhMsxWa iQnEP8SyLyXI1nlBfFXJ0x2k5G0U0/GPAg+CaO/zhjS/GKB1ALysflVoN+z9oEh6 EmOC9uxwnloWHbTyAsbm0rkkrOJeC07vghTYzQZX8y3k89LBg3L4JEBOkZ2T6Pbj VR6926W+SbQee6s13t3uyYbYievXtLmj5nYRbsZc4IwtXoHvuKxvMUVFALsABiXx 4osgemCNEgnuff1xYBv0LEniHAZwphfSuXw+GFYb2hXbRNjOLMzElZkCmddfpSXy wO0nPKMAuT3vbHZ9d1ly4x3BFXFFaOJa1R88/RfRhFnmz0Yut3p2AvG0We7a+5zT us7S8EtZtePqTkBvlF4HpMXKtcN1ZkrM/Nj+OfV3LObyIVNLjuzt3pOZgwEaL8/I /F87lgCvP2OvTuy3eABF =NoFh -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/18] MAINTAINERS: ARM: OMAP2/3: Remove unused clockdomain files
On Sun, 21 Jul 2013, Joe Perches wrote: commit 4bd5259e53a (ARM: OMAP2/3: clockdomain/PRM/CM: move the low-level clockdomain functions into PRM/CM) deleted the files, update the pattern. Signed-off-by: Joe Perches j...@perches.com cc: Paul Walmsley p...@pwsan.com cc: Rajendra Nayak rna...@ti.com cc: Santosh Shilimkar santosh.shilim...@ti.com I don't object to the content of this patch, but Cesar Eduardo Barros posted a patch for this already (and cc'ed you) back in March: http://lkml.indiana.edu/hypermail/linux/kernel/1303.0/00904.html Please take his patch instead, or credit him in your patch. - 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 03/18] MAINTAINERS: OMAP POWERDOMAIN, update patterns
On Sun, 21 Jul 2013, Joe Perches wrote: commit 498153995b9 (ARM: OMAP2+: powerdomain/PRM: move the low-level powerdomain) renamed the files, update the patterns. Signed-off-by: Joe Perches j...@perches.com cc: Paul Walmsley p...@pwsan.com cc: Rajendra Nayak rna...@ti.com cc: Santosh Shilimkar santosh.shilim...@ti.com I don't object to the content of this patch, but Cesar Eduardo Barros posted a patch for this already (and cc'ed you) back in March: http://lkml.indiana.edu/hypermail/linux/kernel/1303.0/00904.html The regex used in his pattern is also more accurate. Please take his patch instead, or credit him in your patch and use the cm*.[ch]/prm*.[ch] notation from his patch. - 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 03/18] MAINTAINERS: OMAP POWERDOMAIN, update patterns
On Mon, 2013-07-22 at 05:03 +, Paul Walmsley wrote: On Sun, 21 Jul 2013, Joe Perches wrote: commit 498153995b9 (ARM: OMAP2+: powerdomain/PRM: move the low-level powerdomain) renamed the files, update the patterns. Signed-off-by: Joe Perches j...@perches.com cc: Paul Walmsley p...@pwsan.com cc: Rajendra Nayak rna...@ti.com cc: Santosh Shilimkar santosh.shilim...@ti.com I don't object to the content of this patch, but Cesar Eduardo Barros posted a patch for this already (and cc'ed you) back in March: http://lkml.indiana.edu/hypermail/linux/kernel/1303.0/00904.html The regex used in his pattern is also more accurate. Please take his patch instead, or credit him in your patch and use the cm*.[ch]/prm*.[ch] notation from his patch. (cc'ing Cesar) Hi Paul. I'm not the MAINTAINERS maintainer and I don't pick up patches. I certainly don't object at all if Andrew picks up the patches you mentioned and drops these 2. Andrew, here are links to Cesar's original patches https://patchwork.kernel.org/project/LKML/list/?submitter=3513 https://lkml.org/lkml/2013/3/2/185 It seems a few are similar/duplicated to these 18. Cesar, maybe you should resend yours. I thought they were applied and forgot all about them. cheers, Joe -- 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: OMAP3EVM: Marking omap3_evm_display_init() with CONFIG_BROKEN
From: Lokesh Vutla lokeshvu...@ti.com
On 37xx EVM non-dt boot fails with current mainline,
because of broken GPIO numbering in the board file
that uses hardcoded GPIOs.
So marking omap3_evm_display_init() with CONFIG_BROKEN
for now as suggested by Tony as per the below link:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg90399.html
Signed-off-by: Lokesh Vutla lokeshvu...@ti.com
Tested-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Tony Lindgren t...@atomide.com
---
Hi -stablers,
OMAP37xx EVM does not boot on v3.10 without this patch, so please consider
it for the v3.10 stable releases. It is upstream already as commit ID
8fb61e8d84e673eebf31e564a83bb71a50b1ed48. Perhaps if I had managed to
test it sooner, we could have gotten it up during v3.10-rc, but, alas,
stable it is...
arch/arm/mach-omap2/board-omap3evm.c |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/mach-omap2/board-omap3evm.c
b/arch/arm/mach-omap2/board-omap3evm.c
index f76d0de..278bf25 100644
--- a/arch/arm/mach-omap2/board-omap3evm.c
+++ b/arch/arm/mach-omap2/board-omap3evm.c
@@ -174,6 +174,7 @@ static struct panel_sharp_ls037v7dw01_data
omap3_evm_lcd_data = {
.ud_gpio = OMAP3EVM_LCD_PANEL_UD,
};
+#ifdef CONFIG_BROKEN
static void __init omap3_evm_display_init(void)
{
int r;
@@ -193,6 +194,7 @@ static void __init omap3_evm_display_init(void)
else
gpio_set_value_cansleep(OMAP3EVM_LCD_PANEL_BKLIGHT_GPIO, 1);
}
+#endif
static struct omap_dss_device omap3_evm_lcd_device = {
.name = lcd,
@@ -715,7 +717,9 @@ static void __init omap3_evm_init(void)
omap_ads7846_init(1, OMAP3_EVM_TS_GPIO, 310, NULL);
omap3evm_init_smsc911x();
+#ifdef CONFIG_BROKEN
omap3_evm_display_init();
+#endif
omap3_evm_wl12xx_init();
omap_twl4030_audio_init(omap3evm, NULL);
}
--
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
--
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 03/18] MAINTAINERS: OMAP POWERDOMAIN, update patterns
Hi Joe, On Sun, 21 Jul 2013, Joe Perches wrote: I certainly don't object at all if Andrew picks up the patches you mentioned and drops these 2. Andrew, here are links to Cesar's original patches https://patchwork.kernel.org/project/LKML/list/?submitter=3513 https://lkml.org/lkml/2013/3/2/185 It seems a few are similar/duplicated to these 18. Cesar, maybe you should resend yours. I thought they were applied and forgot all about them. Another possibility, assuming that there are some fixes from your series that Cesar didn't have, would be for you to take his patches into the series that you're sending to Andrew, assuming that you agree with them. Then we'd benefit from the superset of fixes. regards, - 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 v2 3/4] arm: dts: Add USB phy nodes for AM33XX
On 7/20/2013 9:11 AM, George Cherian wrote:
On 7/20/2013 12:12 AM, Sebastian Andrzej Siewior wrote:
On 07/19/2013 08:33 PM, Sergei Shtylyov wrote:
Hello.
Hello,
usb: usb@4740 {
compatible = ti,am33xx-usb;
usb0_phy: phy@47401300 {
compatible = ti,am335x-usb-phy;
}
usb0: usb@47401000 {
musb0: usb@47401400 {
compatible = mg,musbmhdrc;
}
}
usb1_phy: phy@47402300 {
compatible = ti,am335x-usb-phy;
}
usb1: usb@47402000 {
musb1: usb@47402400 {
compatible = mg,musbmhdrc;
}
}
}
How about something like this ?
Here am making
wrapper - musb instance 0 - phy0
wrapper - musb instance 1 - phy1
musb: usb@4740 {
compatible = ti,musb-am33xx;
reg = 0x4740 0x1000;
ranges;
#address-cells = 1;
#size-cells = 1;
interrupts = 17;
ti,hwmods = usb_otg_hs;
usb0@47401000 {
reg = 0x47401000 0x800;
interrupts = 18;
interrupt-names = mc;
multipoint = 1;
num-eps = 16;
ram-bits = 12;
port-mode = 3;
power = 250;
phys = phy1;
phy-names = am335x-usb0;
phy1: am335x-usb0 {
compatible = ti,am335x-usb2;
#phy-cells = 0;
id= 0;
};
};
usb1@47401800 {
reg = 0x47401800 0x800;
interrupts = 19;
interrupt-names = mc;
multipoint = 1;
num-eps = 16;
ram-bits = 12;
port-mode = 3;
power = 250;
phys = phy2;
phy-names = am335x-usb1;
phy2: am335x-usb1 {
compatible = ti,am335x-usb2;
#phy-cells = 0;
id= 1;
};
};
};
--
-George
--
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
