[PATCH 2.6.39] omap: board-4430sdp: revert hsmmc_info reordering
The order in which the MMC cards are defined in the the 4430sdp board
file seems to have been mistakenly reorderded as part of an unrelated
patch. In commit 0005ae73cfe44ee42d0be12a12cc82bf982f518e, where only
the dev_name was supposed to be changed, the mmc order was changed as
well. This caused the external SD card reader not to be recognized,
at least on Blaze.
This patch reverts this change so that the external SD card is
recognized again.
Cc: Kishore Kadiyala kishore.kadiy...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Luciano Coelho coe...@ti.com
---
I have started investigating the cause for this problem, because it
seems to me that the value in the mmc element is what should matter,
but it doesn't seem to be the case. I believe there is a bug
elsewhere, that causes the order of the array to matter, but I'm not
very familiar with hsmmc and I don't have much time right now to delve
into the problem, so I leave this to the omap people. ;) I can always
help testing if necessary.
The change indeed seems to have been a mistake, because it was
introduced silently in v6:
https://patchwork.kernel.org/patch/595861/
In v5, the change was not there:
https://patchwork.kernel.org/patch/590441/
arch/arm/mach-omap2/board-4430sdp.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 56702c5..8991d56 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -351,6 +351,11 @@ static struct twl4030_usb_data omap4_usbphy_data = {
static struct omap2_hsmmc_info mmc[] = {
{
+ .mmc= 1,
+ .caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
+ .gpio_wp= -EINVAL,
+ },
+ {
.mmc= 2,
.caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
.gpio_cd= -EINVAL,
@@ -358,11 +363,6 @@ static struct omap2_hsmmc_info mmc[] = {
.nonremovable = true,
.ocr_mask = MMC_VDD_29_30,
},
- {
- .mmc= 1,
- .caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
- .gpio_wp= -EINVAL,
- },
{} /* Terminator */
};
--
1.7.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 1/9] OMAP: DSS2: move dss device clock configuration
On Thursday 31 March 2011 03:40 PM, Valkeinen, Tomi wrote:
Clock configuration was defined inside dssdev.phy.dsi struct. The clock
config doesn't really belong there, and so it's moved to dssdev.clock
struct.
Now the explicit clock configuration could also be used for other
interfaces than DSI, although there's no support for it currently.
Signed-off-by: Tomi Valkeinentomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 14 +-
arch/arm/plat-omap/include/plat/display.h | 28
drivers/video/omap2/dss/dsi.c | 14 +++---
3 files changed, 32 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 05288c9..626b16b 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -766,17 +766,21 @@ static struct omap_dss_device sdp4430_lcd_device = {
.data1_pol = 0,
.data2_lane = 3,
.data2_pol = 0,
- .div= {
+ },
+
+ .clocks = {
+ .dispc = {
+ .lck_div= 1,/* Logic Clock = 172.8 MHz */
+ .pck_div= 5,/* Pixel Clock = 34.56 MHz */
+ },
+
+ .dsi = {
.regn = 16, /* Fint = 2.4 MHz */
.regm = 180, /* DDR Clock = 216 MHz */
.regm_dispc = 5,/* PLL1_CLK1 = 172.8 MHz */
.regm_dsi = 5,/* PLL1_CLK2 = 172.8 MHz */
.lp_clk_div = 10, /* LP Clock = 8.64 MHz */
-
- .lck_div= 1,/* Logic Clock = 172.8 MHz */
- .pck_div= 5,/* Pixel Clock = 34.56 MHz */
-
},
},
.channel= OMAP_DSS_CHANNEL_LCD,
diff --git a/arch/arm/plat-omap/include/plat/display.h
b/arch/arm/plat-omap/include/plat/display.h
index 5e04ddc..e10cfe2 100644
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -401,18 +401,6 @@ struct omap_dss_device {
u8 data2_lane;
u8 data2_pol;
- struct {
- u16 regn;
- u16 regm;
- u16 regm_dispc;
- u16 regm_dsi;
-
- u16 lp_clk_div;
-
- u16 lck_div;
- u16 pck_div;
- } div;
-
bool ext_te;
u8 ext_te_gpio;
} dsi;
@@ -424,6 +412,22 @@ struct omap_dss_device {
} phy;
struct {
+ struct {
+ u16 lck_div;
+ u16 pck_div;
Is it possible to wrap these members around a channel member? The board
file can then fill up the lck_div and ppck_div based on what channel it
is using.
Archit
+ } dispc;
+
+ struct {
+ u16 regn;
+ u16 regm;
+ u16 regm_dispc;
+ u16 regm_dsi;
+
+ u16 lp_clk_div;
+ } dsi;
+ } clocks;
+
+ struct {
struct omap_video_timings timings;
int acbi; /* ac-bias pin transitions per interrupt */
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 23d9bbe..7304c87 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -1026,7 +1026,7 @@ static int dsi_set_lp_clk_divisor(struct omap_dss_device
*dssdev)
unsigned lp_clk_div;
unsigned long lp_clk;
- lp_clk_div = dssdev-phy.dsi.div.lp_clk_div;
+ lp_clk_div = dssdev-clocks.dsi.lp_clk_div;
if (lp_clk_div == 0 || lp_clk_div dsi.lpdiv_max)
return -EINVAL;
@@ -3388,10 +3388,10 @@ static int dsi_configure_dsi_clocks(struct
omap_dss_device *dssdev)
/* we always use DSS_CLK_SYSCK as input clock */
cinfo.use_sys_clk = true;
- cinfo.regn = dssdev-phy.dsi.div.regn;
- cinfo.regm = dssdev-phy.dsi.div.regm;
- cinfo.regm_dispc = dssdev-phy.dsi.div.regm_dispc;
- cinfo.regm_dsi = dssdev-phy.dsi.div.regm_dsi;
+ cinfo.regn = dssdev-clocks.dsi.regn;
+ cinfo.regm = dssdev-clocks.dsi.regm;
+ cinfo.regm_dispc = dssdev-clocks.dsi.regm_dispc;
+ cinfo.regm_dsi = dssdev-clocks.dsi.regm_dsi;
r = dsi_calc_clock_rates(dssdev,cinfo);
if (r) {
DSSERR(Failed to calc dsi clocks\n);
@@ -3415,8 +3415,8 @@ static int dsi_configure_dispc_clocks(struct
omap_dss_device *dssdev)
fck = dsi_get_pll_hsdiv_dispc_rate();
- dispc_cinfo.lck_div =
Re: [PATCH 1/9] OMAP: DSS2: move dss device clock configuration
On Fri, 2011-04-01 at 12:35 +0530, Archit Taneja wrote:
On Thursday 31 March 2011 03:40 PM, Valkeinen, Tomi wrote:
Clock configuration was defined inside dssdev.phy.dsi struct. The clock
config doesn't really belong there, and so it's moved to dssdev.clock
struct.
Now the explicit clock configuration could also be used for other
interfaces than DSI, although there's no support for it currently.
Signed-off-by: Tomi Valkeinentomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 14 +-
arch/arm/plat-omap/include/plat/display.h | 28
drivers/video/omap2/dss/dsi.c | 14 +++---
3 files changed, 32 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 05288c9..626b16b 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
snip
@@ -424,6 +412,22 @@ struct omap_dss_device {
} phy;
struct {
+ struct {
+ u16 lck_div;
+ u16 pck_div;
Is it possible to wrap these members around a channel member? The board
file can then fill up the lck_div and ppck_div based on what channel it
is using.
Hmm. What do you mean wrap around? The channel is defined a bit below
there.
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.39] omap: board-4430sdp: revert hsmmc_info reordering
On Fri, Apr 1, 2011 at 12:22 PM, Luciano Coelho coe...@ti.com wrote:
The order in which the MMC cards are defined in the the 4430sdp board
file seems to have been mistakenly reorderded as part of an unrelated
patch. In commit 0005ae73cfe44ee42d0be12a12cc82bf982f518e, where only
the dev_name was supposed to be changed, the mmc order was changed as
well. This caused the external SD card reader not to be recognized,
at least on Blaze.
Both OMAP4 SDP Blaze boards have internal eMMC as storage.
Just think of some scenario as below with FS in eMMC
[with external card recognized as mmcblk0 and eMMC as mmcblk1]:
Booting with both external card on MMC1 and eMMC on MMC2 and having
bootargs set to root=/dev/mmcblk1px [x= parition number].
Removing the external card from slot makes eMMC recognized as mmcblk0 and
in this case kernel can't pick the file system as passed above in the bootargs.
So, making the permanent storage on the boards registered as first
block device gets
rid of the problem.
Regards,
Kishore
This patch reverts this change so that the external SD card is
recognized again.
Cc: Kishore Kadiyala kishore.kadiy...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Luciano Coelho coe...@ti.com
---
I have started investigating the cause for this problem, because it
seems to me that the value in the mmc element is what should matter,
but it doesn't seem to be the case. I believe there is a bug
elsewhere, that causes the order of the array to matter, but I'm not
very familiar with hsmmc and I don't have much time right now to delve
into the problem, so I leave this to the omap people. ;) I can always
help testing if necessary.
The change indeed seems to have been a mistake, because it was
introduced silently in v6:
https://patchwork.kernel.org/patch/595861/
In v5, the change was not there:
https://patchwork.kernel.org/patch/590441/
arch/arm/mach-omap2/board-4430sdp.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 56702c5..8991d56 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -351,6 +351,11 @@ static struct twl4030_usb_data omap4_usbphy_data = {
static struct omap2_hsmmc_info mmc[] = {
{
+ .mmc = 1,
+ .caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
+ .gpio_wp = -EINVAL,
+ },
+ {
.mmc = 2,
.caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
.gpio_cd = -EINVAL,
@@ -358,11 +363,6 @@ static struct omap2_hsmmc_info mmc[] = {
.nonremovable = true,
.ocr_mask = MMC_VDD_29_30,
},
- {
- .mmc = 1,
- .caps = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
- .gpio_wp = -EINVAL,
- },
{} /* Terminator */
};
--
1.7.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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.39] omap: board-4430sdp: revert hsmmc_info reordering
On 4/1/2011 8:52 AM, Coelho, Luciano wrote: The order in which the MMC cards are defined in the the 4430sdp board file seems to have been mistakenly reorderded as part of an unrelated patch. In commit 0005ae73cfe44ee42d0be12a12cc82bf982f518e, where only the dev_name was supposed to be changed, the mmc order was changed as well. This caused the external SD card reader not to be recognized, at least on Blaze. This patch reverts this change so that the external SD card is recognized again. Cc: Kishore Kadiyalakishore.kadiy...@ti.com Cc: Benoit Coussonb-cous...@ti.com Signed-off-by: Luciano Coelhocoe...@ti.com --- I have started investigating the cause for this problem, because it seems to me that the value in the mmc element is what should matter, but it doesn't seem to be the case. I believe there is a bug elsewhere, that causes the order of the array to matter, but I'm not very familiar with hsmmc and I don't have much time right now to delve into the problem, so I leave this to the omap people. ;) I can always help testing if necessary. I was about to make the same comment. Why does the order matter since we have a .mmc field with that information? There is probably something broken behind that. Regards, Benoit -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Thu, 2011-03-31 at 17:23 +0200, Arnd Bergmann wrote: * The DSS display drivers introduce new infrastructure include new bus types that have the complexity to make them completely generic, but in practice can only work on OMAP, and are clearly not written with cross-vendor abstractions in mind. If you mean the panel drivers, then I disagree. They are currently OMAP specific, but they are designed so that making them generic shouldn't be too difficult. It's been my aim for a long time already to make the panel drivers generic, but I've never had time and it's never been quite clear to me what would be the best way to do that. The core DSS driver is OMAP specific, and while the DSS IP could in theory be used in some other platform, that is not currently the case and I wouldn't want to needlessly start abstracting things for just the sake of abstracting. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
* David Brown dav...@codeaurora.org wrote: When we push back, there is a good chance they just won't bother, not because they don't want to do it, but because it doesn't fit a schedule, and there is already something else for them to work on. So what's the right answer here. [...] IMO the right answer is what Linus and Thomas outlined: 1) provide a small number of clean examples and clean abstractions 2) to not pull new crap from that point on 3) do this gradually but consistently I.e. make all your requirements technical and actionable - avoid sweeping, impossible to meet requirements. Do not require people to clean up all of the existing mess straight away (they cannot realistically do it), do not summarily block the flow of patches, but be firm about drawing a line in the sand and be firm about not introducing new mess in a gradually growing list of well-chosen areas of focus. Rinse, repeat. If companies do not 'bother to push upstream', then management will eventually notice negative economic consequences: - Higher short-term production costs: upstream feedback/review/testing improves the product, so the lack of upstream feedback/review/testing increases the production costs of the product. - Higher long-term production costs: gradually slower SoC development due to a morass of out-of-tree hacks that werent pushed upstream causing gradually higher development costs. This means higher payroll costs and longer time to market - in which time more flexible competitors can beat you. - Brain drain: developers like to show their good work upstream as well, not just in some ship-and-forget out-of-tree kernel. Good developers will gravitate towards SoC companies that encourage them to work upstream. No matter how good of a business idea a company has if there's no good developers. - Less revenue: a product can not possibly be more appealing to SoC customers if the upstream Linux kernel does not support it. As ARM moves up the food chain towards more complex, higher profit margin products longer term thinking gains foothold gradually. - Competitive disadvantages: most SoC competitors push their changes upstream, so they get free development assistance, they get free exposure, they get free PR and they get opportunities. Not pushing upstream is a lost opportunity. All of these effects translate into real $$$ and affect the bottom line very directly, both short and long term. These costs also increase with time so they are not fixed. If management does not actively encourage upstream-quality changes then management will have to justify why they exposed the company to these extra costs, complications and risks - just to save on the relatively minor (and fixed) cost of working with upstream. If despite all that management still believes (rightly or wrongly) that it's cheaper for the company to do low quality throw-away code and does not care about any of the short and long-term costs listed above then this really means that they really do not care about you or about the upstream kernel - so they do not exist as far as the upstream kernel is concerned. Why should you then reward them with pulling crap and why should you be willing to invest future maintenance overhead into their we do not care about you solution? Working with upstream is a quid pro quo with plenty of advantages on both sides, which gives maintainers a heck of a leverage to push back on crap while still having all the incentives in the world to help produce a high quality kernel. Thanks, Ingo -- 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/9] OMAP: DSS2: move dss device clock configuration
On Friday 01 April 2011 12:37 PM, Valkeinen, Tomi wrote:
On Fri, 2011-04-01 at 12:35 +0530, Archit Taneja wrote:
On Thursday 31 March 2011 03:40 PM, Valkeinen, Tomi wrote:
Clock configuration was defined inside dssdev.phy.dsi struct. The clock
config doesn't really belong there, and so it's moved to dssdev.clock
struct.
Now the explicit clock configuration could also be used for other
interfaces than DSI, although there's no support for it currently.
Signed-off-by: Tomi Valkeinentomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 14 +-
arch/arm/plat-omap/include/plat/display.h | 28
drivers/video/omap2/dss/dsi.c | 14 +++---
3 files changed, 32 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 05288c9..626b16b 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
snip
@@ -424,6 +412,22 @@ struct omap_dss_device {
} phy;
struct {
+ struct {
+ u16 lck_div;
+ u16 pck_div;
Is it possible to wrap these members around a channel member? The board
file can then fill up the lck_div and ppck_div based on what channel it
is using.
Hmm. What do you mean wrap around? The channel is defined a bit below
there.
I meant something like:
...
struct {
struct {
struct {
u16 lck_div;
u16 pck_div;
} channel[MAX_CHANNELS];
} dispc;
...
struct {
} dsi;
} clocks;
...
Or something equivalent to the thing above, like using a pointer to an
array.
Archit
--
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/9] OMAP: DSS2: move dss device clock configuration
On Fri, 2011-04-01 at 13:21 +0530, Archit Taneja wrote:
On Friday 01 April 2011 12:37 PM, Valkeinen, Tomi wrote:
On Fri, 2011-04-01 at 12:35 +0530, Archit Taneja wrote:
On Thursday 31 March 2011 03:40 PM, Valkeinen, Tomi wrote:
Clock configuration was defined inside dssdev.phy.dsi struct. The clock
config doesn't really belong there, and so it's moved to dssdev.clock
struct.
Now the explicit clock configuration could also be used for other
interfaces than DSI, although there's no support for it currently.
Signed-off-by: Tomi Valkeinentomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 14 +-
arch/arm/plat-omap/include/plat/display.h | 28
drivers/video/omap2/dss/dsi.c | 14 +++---
3 files changed, 32 insertions(+), 24 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 05288c9..626b16b 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
snip
@@ -424,6 +412,22 @@ struct omap_dss_device {
} phy;
struct {
+ struct {
+ u16 lck_div;
+ u16 pck_div;
Is it possible to wrap these members around a channel member? The board
file can then fill up the lck_div and ppck_div based on what channel it
is using.
Hmm. What do you mean wrap around? The channel is defined a bit below
there.
I meant something like:
...
struct {
struct {
struct {
u16 lck_div;
u16 pck_div;
} channel[MAX_CHANNELS];
} dispc;
...
struct {
} dsi;
} clocks;
...
Or something equivalent to the thing above, like using a pointer to an
array.
What would be the benefit of that? A dss device can be connected only to
one channel. Now we have the dividers and the channel defined, and
omapdss can use this info to configure the dividers for that channel
properly.
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/9] OMAP: DSS2: move dss device clock configuration
On Friday 01 April 2011 01:20 PM, Valkeinen, Tomi wrote:
On Fri, 2011-04-01 at 13:21 +0530, Archit Taneja wrote:
On Friday 01 April 2011 12:37 PM, Valkeinen, Tomi wrote:
On Fri, 2011-04-01 at 12:35 +0530, Archit Taneja wrote:
On Thursday 31 March 2011 03:40 PM, Valkeinen, Tomi wrote:
Clock configuration was defined inside dssdev.phy.dsi struct. The clock
config doesn't really belong there, and so it's moved to dssdev.clock
struct.
Now the explicit clock configuration could also be used for other
interfaces than DSI, although there's no support for it currently.
Signed-off-by: Tomi Valkeinentomi.valkei...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c | 14 +-
arch/arm/plat-omap/include/plat/display.h | 28
drivers/video/omap2/dss/dsi.c | 14 +++---
3 files changed, 32 insertions(+), 24 deletions(-)
snip
I meant something like:
...
struct {
struct {
struct {
u16 lck_div;
u16 pck_div;
} channel[MAX_CHANNELS];
} dispc;
...
struct {
} dsi;
} clocks;
...
Or something equivalent to the thing above, like using a pointer to an
array.
What would be the benefit of that? A dss device can be connected only to
one channel. Now we have the dividers and the channel defined, and
omapdss can use this info to configure the dividers for that channel
properly.
Okay, I guess channel wasn't the best example to explain my point, and I
guess its safe for dss device not to touch any other channels (currently
ignoring complex bridge chips which can merge data of 2 LCD channels
onto one panel).
But there are some parameters which might get common across dss devices.
Things like dispc clock source, dispc core clock divider will be shared
across the panels. We had discussed the possibility of declaring this
common info in omap_dss_board_info or as a separate common_clocks
structure. Each device could pick this filled up common_clocks struct,
or fill it up its own way (for the use cases which has only one panel on
at a time). I was wondering if it would be easy to move to this approach
with your patch. dispc itself would now have some common clock stuff and
per panel clock stuff. Is that a very clean approach?
Anyway, I think it would be good to have a channel struct, as there are
more things to put in dispc clocks, it should look something like:
struct clocks {
struct {
struct {
u16 lck_div;
u16 pck_div;
enum clock_source lcd_clk_src;
} channel;
...
...
u16 core_clk_div;
} dispc;
...
...
};
Archit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.39] omap: board-4430sdp: revert hsmmc_info reordering
On Fri, 2011-04-01 at 12:46 +0530, Kishore Kadiyala wrote: On Fri, Apr 1, 2011 at 12:22 PM, Luciano Coelho coe...@ti.com wrote: The order in which the MMC cards are defined in the the 4430sdp board file seems to have been mistakenly reorderded as part of an unrelated patch. In commit 0005ae73cfe44ee42d0be12a12cc82bf982f518e, where only the dev_name was supposed to be changed, the mmc order was changed as well. This caused the external SD card reader not to be recognized, at least on Blaze. Both OMAP4 SDP Blaze boards have internal eMMC as storage. Just think of some scenario as below with FS in eMMC [with external card recognized as mmcblk0 and eMMC as mmcblk1]: Booting with both external card on MMC1 and eMMC on MMC2 and having bootargs set to root=/dev/mmcblk1px [x= parition number]. Removing the external card from slot makes eMMC recognized as mmcblk0 and in this case kernel can't pick the file system as passed above in the bootargs. Yes, this makes sense. The internal eMMC should be mapped first, I agree. So, making the permanent storage on the boards registered as first block device gets rid of the problem. Yes, but there is something wrong that causes the external MMC not to be recognized at all if you map the internal MMC first. There is a bug elsewhere that needs to be fixed before this change can be made. As I said, I don't know much about the OMAP MMC subsystem and I don't have the time right now to investigate what really is wrong. That's why I sent this patch, as quick fix (or rather getting rid of a regression). Another thing is that this is a crosspatch change. It shouldn't be part of the same patch that changes the name of the driver, since this is totally unrelated. If you really think this needs to be done, it should have been done in a separate patch. -- Cheers, 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 2.6.39] omap: board-4430sdp: revert hsmmc_info reordering
On Fri, 2011-04-01 at 09:18 +0200, Cousson, Benoit wrote: On 4/1/2011 8:52 AM, Coelho, Luciano wrote: The order in which the MMC cards are defined in the the 4430sdp board file seems to have been mistakenly reorderded as part of an unrelated patch. In commit 0005ae73cfe44ee42d0be12a12cc82bf982f518e, where only the dev_name was supposed to be changed, the mmc order was changed as well. This caused the external SD card reader not to be recognized, at least on Blaze. This patch reverts this change so that the external SD card is recognized again. Cc: Kishore Kadiyalakishore.kadiy...@ti.com Cc: Benoit Coussonb-cous...@ti.com Signed-off-by: Luciano Coelhocoe...@ti.com --- I have started investigating the cause for this problem, because it seems to me that the value in the mmc element is what should matter, but it doesn't seem to be the case. I believe there is a bug elsewhere, that causes the order of the array to matter, but I'm not very familiar with hsmmc and I don't have much time right now to delve into the problem, so I leave this to the omap people. ;) I can always help testing if necessary. I was about to make the same comment. Why does the order matter since we have a .mmc field with that information? There is probably something broken behind that. That's my impression too. From a bird's eye view, it seems that this change should have worked. But there's a bug somewhere, so it doesn't. :( -- Cheers, 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 00/10] omap init_early changes for irq and timer init
On 3/31/2011 11:02 PM, Tony Lindgren wrote: * Santosh Shilimkarsantosh.shilim...@ti.com [110331 01:14]: On 3/30/2011 11:52 PM, Tony Lindgren wrote: What it does not have is the code to dedicate gpt1 for PM code, which can be done later once all the other dmtimer changes are done. Which not possible to do unless you plan to hack generic timer framework or waste additional timer hardware for this. Well an extra timer hardware would only be needed on omap2 3. But hey, if it makes sense to do or not to do is a different set of patches. At least we now have an option to play with it. For removing the old interface, I don't see any reason to select timer combinations on omap3 other than omap3_timer and omap3_beagle_timer. If there's need, any new valid sane combinations can be esily added, although I seriously doubt that we'll need more for omap3. May be I am wrong but the point is about the merit of the solution even if there are only couple of board files where we use that interface. It much cleaner and simpler to say timerid=X, from board file rather than creating a struct sys_timer instance and putting that in timer code. Well the timerid=X adds yet another interface and more calls from board-*.c to the common code. And it requires more changes if beagle boards want to use the system clock as the source clock instead of the 32KiHZ source. Maybe let's call the omap3_beagle_timer omap3_secure_timer instead? That should solve your issue of having the board name show up in the generic code, no? Sorry about picking up on names but that was not my point. I agree with you on reducing interfaces so I step back on this point. At least I don't see other solution than using GPT1 for wakeup. Right, there's no other way to wake except gpt1 or wake-up enabled gpio lines. But we don't need to use gpt1 during runtime at all. This is not entirely correct and I think this is the point where we are not on same page. During runtime, gpt1 clock event is not used for tick generation but it's kept programmed because low power state switch via get triggered any time and on any CPU. Well ideally we would not program it during runtime at all because it's slow to program. I don't think that can be currently done with the sys_timer. This is the same problem as X86 APIC timer + HPET switching and I worked with Thomas G and Russell to get this working on ARM platforms using generic timer framework. No hacking is needed in PM code for this. Except we should improve things eventually where we don't need to program the slow external timer during runtime if we have local timers. This is already the case now. On OMAP4 running system, CPU use their own local timers and rq's. There is no broadcasting. Whenever there is a need of it like the situations where local-timers die (low power states), timer system switches to broad-cast timer which is wakeup capable. GPT1 in our case. This is all managed by timer framework and works seamlessly. Hmm maybe I'm wrong and you got that working already? I don't think you are wrong. All your points are correct. The only missing point was the necessity of GPT1 registered as clock-event to allow dynamic switching between clock-events. That's where I was saying that we are not left with GPT1 for PM debug feature. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/9] OMAP: DSS2: move dss device clock configuration
On Fri, 2011-04-01 at 13:49 +0530, Archit Taneja wrote:
But there are some parameters which might get common across dss devices.
Things like dispc clock source, dispc core clock divider will be shared
across the panels. We had discussed the possibility of declaring this
common info in omap_dss_board_info or as a separate common_clocks
structure. Each device could pick this filled up common_clocks struct,
or fill it up its own way (for the use cases which has only one panel on
at a time). I was wondering if it would be easy to move to this approach
with your patch. dispc itself would now have some common clock stuff and
per panel clock stuff. Is that a very clean approach?
I don't know =). I think the simplest solution is to have full divisor
info for each dss_device. And it's up to the board file writer to make
sure the divisors match for all the displays that can be enabled at the
same time.
I don't think that is perfect, but trying to share the data sounds a bit
confusing. Especially as there are just a divisor and a clock source
that are shared. If we have a lot of common data, then a shared struct
would of course be better.
Anyway, I think it would be good to have a channel struct, as there are
more things to put in dispc clocks, it should look something like:
struct clocks {
struct {
struct {
u16 lck_div;
u16 pck_div;
enum clock_source lcd_clk_src;
} channel;
...
...
u16 core_clk_div;
} dispc;
...
...
};
In my original patch I had:
struct {
struct {
u16 fck_div;
} dss;
struct {
u16 lck_div;
u16 pck_div;
bool fclk_from_dsi_pll;
} dispc;
...
};
Which I removed due to comments and slight confusion how to handle the
DSS_FCLK divisor and the clock source.
Adding the clock source there needs some more work, moving the enum to
public include file, and implementing the support. If you agree that
this patch in its current form is an improvement, I'd like to go forward
with this and work on the clock source later.
Tomi
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/9] OMAP: DSS2: move dss device clock configuration
On Friday 01 April 2011 02:09 PM, Valkeinen, Tomi wrote:
On Fri, 2011-04-01 at 13:49 +0530, Archit Taneja wrote:
But there are some parameters which might get common across dss devices.
Things like dispc clock source, dispc core clock divider will be shared
across the panels. We had discussed the possibility of declaring this
common info in omap_dss_board_info or as a separate common_clocks
structure. Each device could pick this filled up common_clocks struct,
or fill it up its own way (for the use cases which has only one panel on
at a time). I was wondering if it would be easy to move to this approach
with your patch. dispc itself would now have some common clock stuff and
per panel clock stuff. Is that a very clean approach?
I don't know =). I think the simplest solution is to have full divisor
info for each dss_device. And it's up to the board file writer to make
sure the divisors match for all the displays that can be enabled at the
same time.
I don't think that is perfect, but trying to share the data sounds a bit
confusing. Especially as there are just a divisor and a clock source
that are shared. If we have a lot of common data, then a shared struct
would of course be better.
Anyway, I think it would be good to have a channel struct, as there are
more things to put in dispc clocks, it should look something like:
struct clocks {
struct {
struct {
u16 lck_div;
u16 pck_div;
enum clock_source lcd_clk_src;
} channel;
...
...
u16 core_clk_div;
} dispc;
...
...
};
In my original patch I had:
struct {
struct {
u16 fck_div;
} dss;
struct {
u16 lck_div;
u16 pck_div;
bool fclk_from_dsi_pll;
} dispc;
...
};
Which I removed due to comments and slight confusion how to handle the
DSS_FCLK divisor and the clock source.
Adding the clock source there needs some more work, moving the enum to
public include file, and implementing the support. If you agree that
this patch in its current form is an improvement, I'd like to go forward
with this and work on the clock source later.
Yeah it is, sure.
Archit
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] ARM: GIC: Convert GIC library to use the IO relaxed operations
The GIC register accesses today make use of readl()/writel()
which prove to be very expensive when used along with mandatory
barriers. This mandatory barriers also introduces an un-necessary
and expensive l2x0_sync() operation. On Cortex-A9 MP cores, GIC
IO accesses from CPU are direct and doesn't go through L2X0 write
buffer.
Also since a DSB does not guarantee that the device state has
been changed, a read back from the device is introduced wherever
necessary.
Signed-off-by: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Catalin Marinas catalin.mari...@arm.com
Cc: Will Deacon will.dea...@arm.com
---
V2:
Incorporated comments from Catalin Marinas.
Boot tested with OMAP4430 SDP.
arch/arm/common/gic.c | 49 +
1 files changed, 25 insertions(+), 24 deletions(-)
diff --git a/arch/arm/common/gic.c b/arch/arm/common/gic.c
index f70ec7d..98f9137 100644
--- a/arch/arm/common/gic.c
+++ b/arch/arm/common/gic.c
@@ -89,7 +89,7 @@ static void gic_ack_irq(struct irq_data *d)
spin_lock(irq_controller_lock);
if (gic_arch_extn.irq_ack)
gic_arch_extn.irq_ack(d);
- writel(gic_irq(d), gic_cpu_base(d) + GIC_CPU_EOI);
+ writel_relaxed(gic_irq(d), gic_cpu_base(d) + GIC_CPU_EOI);
spin_unlock(irq_controller_lock);
}
@@ -98,7 +98,8 @@ static void gic_mask_irq(struct irq_data *d)
u32 mask = 1 (d-irq % 32);
spin_lock(irq_controller_lock);
- writel(mask, gic_dist_base(d) + GIC_DIST_ENABLE_CLEAR + (gic_irq(d) /
32) * 4);
+ writel_relaxed(mask, gic_dist_base(d) + GIC_DIST_ENABLE_CLEAR +
(gic_irq(d) / 32) * 4);
+ readl_relaxed(gic_dist_base(d) + GIC_DIST_ENABLE_CLEAR + (gic_irq(d) /
32) * 4);
if (gic_arch_extn.irq_mask)
gic_arch_extn.irq_mask(d);
spin_unlock(irq_controller_lock);
@@ -111,7 +112,7 @@ static void gic_unmask_irq(struct irq_data *d)
spin_lock(irq_controller_lock);
if (gic_arch_extn.irq_unmask)
gic_arch_extn.irq_unmask(d);
- writel(mask, gic_dist_base(d) + GIC_DIST_ENABLE_SET + (gic_irq(d) / 32)
* 4);
+ writel_relaxed(mask, gic_dist_base(d) + GIC_DIST_ENABLE_SET +
(gic_irq(d) / 32) * 4);
spin_unlock(irq_controller_lock);
}
@@ -138,7 +139,7 @@ static int gic_set_type(struct irq_data *d, unsigned int
type)
if (gic_arch_extn.irq_set_type)
gic_arch_extn.irq_set_type(d, type);
- val = readl(base + GIC_DIST_CONFIG + confoff);
+ val = readl_relaxed(base + GIC_DIST_CONFIG + confoff);
if (type == IRQ_TYPE_LEVEL_HIGH)
val = ~confmask;
else if (type == IRQ_TYPE_EDGE_RISING)
@@ -148,15 +149,15 @@ static int gic_set_type(struct irq_data *d, unsigned int
type)
* As recommended by the spec, disable the interrupt before changing
* the configuration
*/
- if (readl(base + GIC_DIST_ENABLE_SET + enableoff) enablemask) {
- writel(enablemask, base + GIC_DIST_ENABLE_CLEAR + enableoff);
+ if (readl_relaxed(base + GIC_DIST_ENABLE_SET + enableoff) enablemask)
{
+ writel_relaxed(enablemask, base + GIC_DIST_ENABLE_CLEAR +
enableoff);
enabled = true;
}
- writel(val, base + GIC_DIST_CONFIG + confoff);
+ writel_relaxed(val, base + GIC_DIST_CONFIG + confoff);
if (enabled)
- writel(enablemask, base + GIC_DIST_ENABLE_SET + enableoff);
+ writel_relaxed(enablemask, base + GIC_DIST_ENABLE_SET +
enableoff);
spin_unlock(irq_controller_lock);
@@ -188,8 +189,8 @@ static int gic_set_affinity(struct irq_data *d, const
struct cpumask *mask_val,
spin_lock(irq_controller_lock);
d-node = cpu;
- val = readl(reg) ~mask;
- writel(val | bit, reg);
+ val = readl_relaxed(reg) ~mask;
+ writel_relaxed(val | bit, reg);
spin_unlock(irq_controller_lock);
return 0;
@@ -222,7 +223,7 @@ static void gic_handle_cascade_irq(unsigned int irq, struct
irq_desc *desc)
chip-irq_ack(desc-irq_data);
spin_lock(irq_controller_lock);
- status = readl(chip_data-cpu_base + GIC_CPU_INTACK);
+ status = readl_relaxed(chip_data-cpu_base + GIC_CPU_INTACK);
spin_unlock(irq_controller_lock);
gic_irq = (status 0x3ff);
@@ -272,13 +273,13 @@ static void __init gic_dist_init(struct gic_chip_data
*gic,
cpumask |= cpumask 8;
cpumask |= cpumask 16;
- writel(0, base + GIC_DIST_CTRL);
+ writel_relaxed(0, base + GIC_DIST_CTRL);
/*
* Find out how many interrupts are supported.
* The GIC only supports up to 1020 interrupt sources.
*/
- gic_irqs = readl(base + GIC_DIST_CTR) 0x1f;
+ gic_irqs = readl_relaxed(base + GIC_DIST_CTR) 0x1f;
gic_irqs = (gic_irqs + 1) * 32;
if (gic_irqs 1020)
gic_irqs = 1020;
@@ -287,26 +288,26 @@ static
Re: [PATCHv2] omap: rx51: Platform support for lp5523 led chip
Hi Felipe,
On 03/31/2011 06:44 PM, ext Felipe Balbi wrote:
On Thu, Mar 31, 2011 at 06:30:32PM +0300, Ameya Palande wrote:
Hi Felipe,
On 03/31/2011 05:26 PM, ext Felipe Balbi wrote:
Hi,
On Thu, Mar 31, 2011 at 04:38:12PM +0300, Ameya Palande wrote:
+static int rx51_lp5523_setup(void)
+{
+ int err;
+
+ err = gpio_request_one(RX51_LP5523_CHIP_EN_GPIO, GPIOF_DIR_OUT,
+ lp5523_enable);
+ if (err 0) {
+ pr_err(Unable to get lp5523_enable GPIO\n);
+ return err;
+ }
+
+ return err;
isn't enough to return gpio_request_one(RX51_LP5523_CHIP_EN_GPIO,
GPIOF_DIR_OUT, lp5523_enable); ??
But then we won't know the failure reason for lp5523_probe()
I would prefer printing an error!
see that both gpio_request() and gpio_direction_output() have debugging
prints for error cases ;-)
Agreed :) Thanks for the review!
Will send v3.
Cheers,
Ameya.
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] OMAP: DSS2: make omap_dss_(un)register_device static
omap_dss_register_device and omap_dss_unregister_device can only be
called from core.c, so we can make it static.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/plat-omap/include/plat/display.h |3 ---
drivers/video/omap2/dss/core.c|7 +--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/display.h
b/arch/arm/plat-omap/include/plat/display.h
index 5e04ddc..e239a0d 100644
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -519,9 +519,6 @@ struct omap_dss_driver {
int omap_dss_register_driver(struct omap_dss_driver *);
void omap_dss_unregister_driver(struct omap_dss_driver *);
-int omap_dss_register_device(struct omap_dss_device *);
-void omap_dss_unregister_device(struct omap_dss_device *);
-
void omap_dss_get_device(struct omap_dss_device *dssdev);
void omap_dss_put_device(struct omap_dss_device *dssdev);
#define for_each_dss_dev(d) while ((d = omap_dss_get_next_device(d)) != NULL)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 1aa2ed1..9bcb0b8 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -54,6 +54,9 @@ unsigned int dss_debug;
module_param_named(debug, dss_debug, bool, 0644);
#endif
+static int omap_dss_register_device(struct omap_dss_device *);
+static void omap_dss_unregister_device(struct omap_dss_device *);
+
/* REGULATORS */
struct regulator *dss_get_vdds_dsi(void)
@@ -480,7 +483,7 @@ static void omap_dss_dev_release(struct device *dev)
reset_device(dev, 0);
}
-int omap_dss_register_device(struct omap_dss_device *dssdev)
+static int omap_dss_register_device(struct omap_dss_device *dssdev)
{
static int dev_num;
@@ -494,7 +497,7 @@ int omap_dss_register_device(struct omap_dss_device *dssdev)
return device_register(dssdev-dev);
}
-void omap_dss_unregister_device(struct omap_dss_device *dssdev)
+static void omap_dss_unregister_device(struct omap_dss_device *dssdev)
{
device_unregister(dssdev-dev);
}
--
1.7.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
[PATCH 2/5] OMAP: DSS2: add __inits to omapdss driver
We can use platform_driver_probe() instead of platform_driver_register()
and thus add __init to many functions in omapdss driver.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/dss/core.c | 15 +++
drivers/video/omap2/dss/dispc.c|7 +++
drivers/video/omap2/dss/dpi.c |2 +-
drivers/video/omap2/dss/dsi.c |7 +++
drivers/video/omap2/dss/dss.c |9 -
drivers/video/omap2/dss/dss_features.c |2 +-
drivers/video/omap2/dss/hdmi.c |8
drivers/video/omap2/dss/manager.c |2 +-
drivers/video/omap2/dss/overlay.c |2 +-
drivers/video/omap2/dss/rfbi.c |7 +++
drivers/video/omap2/dss/sdi.c |2 +-
drivers/video/omap2/dss/venc.c |7 +++
12 files changed, 32 insertions(+), 38 deletions(-)
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 9bcb0b8..3584e3e 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -109,7 +109,7 @@ static const struct file_operations dss_debug_fops = {
static struct dentry *dss_debugfs_dir;
-static int dss_initialize_debugfs(void)
+static int __init dss_initialize_debugfs(void)
{
dss_debugfs_dir = debugfs_create_dir(omapdss, NULL);
if (IS_ERR(dss_debugfs_dir)) {
@@ -156,7 +156,7 @@ static void dss_uninitialize_debugfs(void)
debugfs_remove_recursive(dss_debugfs_dir);
}
#else /* CONFIG_DEBUG_FS CONFIG_OMAP2_DSS_DEBUG_SUPPORT */
-static inline int dss_initialize_debugfs(void)
+static inline int __init dss_initialize_debugfs(void)
{
return 0;
}
@@ -166,7 +166,7 @@ static inline void dss_uninitialize_debugfs(void)
#endif /* CONFIG_DEBUG_FS CONFIG_OMAP2_DSS_DEBUG_SUPPORT */
/* PLATFORM DEVICE */
-static int omap_dss_probe(struct platform_device *pdev)
+static int __init omap_dss_probe(struct platform_device *pdev)
{
struct omap_dss_board_info *pdata = pdev-dev.platform_data;
int r;
@@ -307,7 +307,6 @@ static int omap_dss_resume(struct platform_device *pdev)
}
static struct platform_driver omap_dss_driver = {
- .probe = omap_dss_probe,
.remove = omap_dss_remove,
.shutdown = omap_dss_shutdown,
.suspend= omap_dss_suspend,
@@ -483,7 +482,7 @@ static void omap_dss_dev_release(struct device *dev)
reset_device(dev, 0);
}
-static int omap_dss_register_device(struct omap_dss_device *dssdev)
+static int __init omap_dss_register_device(struct omap_dss_device *dssdev)
{
static int dev_num;
@@ -503,7 +502,7 @@ static void omap_dss_unregister_device(struct
omap_dss_device *dssdev)
}
/* BUS */
-static int omap_dss_bus_register(void)
+static int __init omap_dss_bus_register(void)
{
int r;
@@ -542,7 +541,7 @@ static int __init omap_dss_init(void)
if (r)
return r;
- r = platform_driver_register(omap_dss_driver);
+ r = platform_driver_probe(omap_dss_driver, omap_dss_probe);
if (r) {
omap_dss_bus_unregister();
return r;
@@ -578,7 +577,7 @@ static int __init omap_dss_init(void)
static int __init omap_dss_init2(void)
{
- return platform_driver_register(omap_dss_driver);
+ return platform_driver_probe(omap_dss_driver, omap_dss_probe);
}
core_initcall(omap_dss_init);
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 7804779..8cfc9f0 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3419,7 +3419,7 @@ int dispc_setup_plane(enum omap_plane plane,
}
/* DISPC HW IP initialisation */
-static int omap_dispchw_probe(struct platform_device *pdev)
+static int __init omap_dispchw_probe(struct platform_device *pdev)
{
u32 rev;
int r = 0;
@@ -3491,7 +3491,6 @@ static int omap_dispchw_remove(struct platform_device
*pdev)
}
static struct platform_driver omap_dispchw_driver = {
- .probe = omap_dispchw_probe,
.remove = omap_dispchw_remove,
.driver = {
.name = omapdss_dispc,
@@ -3499,9 +3498,9 @@ static struct platform_driver omap_dispchw_driver = {
},
};
-int dispc_init_platform_driver(void)
+int __init dispc_init_platform_driver(void)
{
- return platform_driver_register(omap_dispchw_driver);
+ return platform_driver_probe(omap_dispchw_driver, omap_dispchw_probe);
}
void dispc_uninit_platform_driver(void)
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index 2d3ca4c..4e8ea50 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -319,7 +319,7 @@ int dpi_init_display(struct omap_dss_device *dssdev)
return 0;
}
-int dpi_init(void)
+int __init dpi_init(void)
{
return 0;
}
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index
[PATCH 0/5] OMAP: DSS: add __inits and __exits
These patches add __inits and __exits to multiple functions in omapdss and panel drivers. Also omap_dss_register_driver_probe() is added which allows us to define panel driver probe functions as __init. This moved almost 7kB from .text section to .init section on my configuration. Tomi Valkeinen (5): OMAP: DSS2: make omap_dss_(un)register_device static OMAP: DSS2: add __inits to omapdss driver OMAP: DSS2: use __exit for selected panel drivers OMAP: DSS2: Add omap_dss_register_driver_probe() OMAP: DSS2: use omap_dss_register_driver_probe() in selected drivers arch/arm/plat-omap/include/plat/display.h |5 +- drivers/video/omap2/displays/panel-generic-dpi.c | 10 ++-- .../video/omap2/displays/panel-sharp-ls037v7dw01.c | 10 ++-- drivers/video/omap2/displays/panel-taal.c |9 +-- drivers/video/omap2/dss/core.c | 64 +--- drivers/video/omap2/dss/dispc.c|7 +- drivers/video/omap2/dss/dpi.c |2 +- drivers/video/omap2/dss/dsi.c |7 +- drivers/video/omap2/dss/dss.c |9 +-- drivers/video/omap2/dss/dss_features.c |2 +- drivers/video/omap2/dss/hdmi.c |8 +- drivers/video/omap2/dss/manager.c |2 +- drivers/video/omap2/dss/overlay.c |2 +- drivers/video/omap2/dss/rfbi.c |7 +- drivers/video/omap2/dss/sdi.c |2 +- drivers/video/omap2/dss/venc.c |7 +- 16 files changed, 96 insertions(+), 57 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] OMAP: DSS2: use __exit for selected panel drivers
We can use __exit for the driver remove function in plain dss panels
(ie. those that do not need i2c or spi).
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays/panel-generic-dpi.c |4 ++--
.../video/omap2/displays/panel-sharp-ls037v7dw01.c |4 ++--
drivers/video/omap2/displays/panel-taal.c |4 ++--
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c
b/drivers/video/omap2/displays/panel-generic-dpi.c
index 4a9b9ff..e359f93 100644
--- a/drivers/video/omap2/displays/panel-generic-dpi.c
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -285,7 +285,7 @@ static int generic_dpi_panel_probe(struct omap_dss_device
*dssdev)
return 0;
}
-static void generic_dpi_panel_remove(struct omap_dss_device *dssdev)
+static void __exit generic_dpi_panel_remove(struct omap_dss_device *dssdev)
{
struct panel_drv_data *drv_data = dev_get_drvdata(dssdev-dev);
@@ -358,7 +358,7 @@ static int generic_dpi_panel_check_timings(struct
omap_dss_device *dssdev,
static struct omap_dss_driver dpi_driver = {
.probe = generic_dpi_panel_probe,
- .remove = generic_dpi_panel_remove,
+ .remove = __exit_p(generic_dpi_panel_remove),
.enable = generic_dpi_panel_enable,
.disable= generic_dpi_panel_disable,
diff --git a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
index d2b35d2..c772747 100644
--- a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
@@ -120,7 +120,7 @@ static int sharp_ls_panel_probe(struct omap_dss_device
*dssdev)
return 0;
}
-static void sharp_ls_panel_remove(struct omap_dss_device *dssdev)
+static void __exit sharp_ls_panel_remove(struct omap_dss_device *dssdev)
{
struct sharp_data *sd = dev_get_drvdata(dssdev-dev);
struct backlight_device *bl = sd-bl;
@@ -205,7 +205,7 @@ static int sharp_ls_panel_resume(struct omap_dss_device
*dssdev)
static struct omap_dss_driver sharp_ls_driver = {
.probe = sharp_ls_panel_probe,
- .remove = sharp_ls_panel_remove,
+ .remove = __exit_p(sharp_ls_panel_remove),
.enable = sharp_ls_panel_enable,
.disable= sharp_ls_panel_disable,
diff --git a/drivers/video/omap2/displays/panel-taal.c
b/drivers/video/omap2/displays/panel-taal.c
index adc9900..490998f 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -819,7 +819,7 @@ err:
return r;
}
-static void taal_remove(struct omap_dss_device *dssdev)
+static void __exit taal_remove(struct omap_dss_device *dssdev)
{
struct taal_data *td = dev_get_drvdata(dssdev-dev);
struct nokia_dsi_panel_data *panel_data = get_panel_data(dssdev);
@@ -1557,7 +1557,7 @@ static enum omap_dss_update_mode taal_get_update_mode(
static struct omap_dss_driver taal_driver = {
.probe = taal_probe,
- .remove = taal_remove,
+ .remove = __exit_p(taal_remove),
.enable = taal_enable,
.disable= taal_disable,
--
1.7.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
[PATCH 4/5] OMAP: DSS2: Add omap_dss_register_driver_probe()
Implement omap_dss_register_driver_probe() function, which is similar to
platform_driver_probe(). omap_dss_register_driver_probe will add the
driver and probe devices in one go, thus enabling us to use __init for
panel probe functions.
Also, if no devices are found in omap_dss_register_driver_probe(), the
function will return -ENODEV, which causes the panel driver module to be
unloaded.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
arch/arm/plat-omap/include/plat/display.h |2 +
drivers/video/omap2/dss/core.c| 44 +
2 files changed, 46 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/display.h
b/arch/arm/plat-omap/include/plat/display.h
index e239a0d..226a78f 100644
--- a/arch/arm/plat-omap/include/plat/display.h
+++ b/arch/arm/plat-omap/include/plat/display.h
@@ -517,6 +517,8 @@ struct omap_dss_driver {
};
int omap_dss_register_driver(struct omap_dss_driver *);
+int omap_dss_register_driver_probe(struct omap_dss_driver *,
+ int (*probe)(struct omap_dss_device *));
void omap_dss_unregister_driver(struct omap_dss_driver *);
void omap_dss_get_device(struct omap_dss_device *dssdev);
diff --git a/drivers/video/omap2/dss/core.c b/drivers/video/omap2/dss/core.c
index 3584e3e..b3eba14 100644
--- a/drivers/video/omap2/dss/core.c
+++ b/drivers/video/omap2/dss/core.c
@@ -447,6 +447,50 @@ void omap_dss_unregister_driver(struct omap_dss_driver
*dssdriver)
}
EXPORT_SYMBOL(omap_dss_unregister_driver);
+static int omap_dss_driver_probe_fail(struct device *dev)
+{
+ return -ENXIO;
+}
+
+static int find_any_dev(struct device *dev, void *data)
+{
+ struct omap_dss_driver *dssdrv = data;
+ return dev-driver == dssdrv-driver;
+}
+
+int omap_dss_register_driver_probe(struct omap_dss_driver *dssdriver,
+ int (*probe)(struct omap_dss_device *))
+{
+ int r;
+
+ /* make sure driver won't have bind/unbind attributes */
+ dssdriver-driver.suppress_bind_attrs = true;
+
+ /* temporary section violation during probe() */
+ dssdriver-probe = probe;
+ r = omap_dss_register_driver(dssdriver);
+
+ /* fixup that section violation */
+
+ dssdriver-probe = NULL;
+ dssdriver-driver.probe = omap_dss_driver_probe_fail;
+
+ if (r)
+ return r;
+
+ /* find any device using this driver */
+ r = bus_for_each_dev(dss_bus_type, NULL, dssdriver, find_any_dev);
+
+ if (r == 0) {
+ /* no devices for this driver */
+ omap_dss_unregister_driver(dssdriver);
+ return -ENODEV;
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(omap_dss_register_driver_probe);
+
/* DEVICE */
static void reset_device(struct device *dev, int check)
{
--
1.7.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
[PATCH 5/5] OMAP: DSS2: use omap_dss_register_driver_probe() in selected drivers
Use omap_dss_register_driver_probe() in plain dss panel drivers, which
allows us to use __init for the driver probe functions.
Signed-off-by: Tomi Valkeinen tomi.valkei...@ti.com
---
drivers/video/omap2/displays/panel-generic-dpi.c |6 +++---
.../video/omap2/displays/panel-sharp-ls037v7dw01.c |6 +++---
drivers/video/omap2/displays/panel-taal.c |5 ++---
3 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/video/omap2/displays/panel-generic-dpi.c
b/drivers/video/omap2/displays/panel-generic-dpi.c
index e359f93..010ea4e 100644
--- a/drivers/video/omap2/displays/panel-generic-dpi.c
+++ b/drivers/video/omap2/displays/panel-generic-dpi.c
@@ -246,7 +246,7 @@ static void generic_dpi_panel_power_off(struct
omap_dss_device *dssdev)
omapdss_dpi_display_disable(dssdev);
}
-static int generic_dpi_panel_probe(struct omap_dss_device *dssdev)
+static int __init generic_dpi_panel_probe(struct omap_dss_device *dssdev)
{
struct panel_generic_dpi_data *panel_data = get_panel_data(dssdev);
struct panel_config *panel_config = NULL;
@@ -357,7 +357,6 @@ static int generic_dpi_panel_check_timings(struct
omap_dss_device *dssdev,
}
static struct omap_dss_driver dpi_driver = {
- .probe = generic_dpi_panel_probe,
.remove = __exit_p(generic_dpi_panel_remove),
.enable = generic_dpi_panel_enable,
@@ -377,7 +376,8 @@ static struct omap_dss_driver dpi_driver = {
static int __init generic_dpi_panel_drv_init(void)
{
- return omap_dss_register_driver(dpi_driver);
+ return omap_dss_register_driver_probe(dpi_driver,
+ generic_dpi_panel_probe);
}
static void __exit generic_dpi_panel_drv_exit(void)
diff --git a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
index c772747..2cf3c9f 100644
--- a/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
+++ b/drivers/video/omap2/displays/panel-sharp-ls037v7dw01.c
@@ -79,7 +79,7 @@ static const struct backlight_ops sharp_ls_bl_ops = {
-static int sharp_ls_panel_probe(struct omap_dss_device *dssdev)
+static int __init sharp_ls_panel_probe(struct omap_dss_device *dssdev)
{
struct backlight_properties props;
struct backlight_device *bl;
@@ -204,7 +204,6 @@ static int sharp_ls_panel_resume(struct omap_dss_device
*dssdev)
}
static struct omap_dss_driver sharp_ls_driver = {
- .probe = sharp_ls_panel_probe,
.remove = __exit_p(sharp_ls_panel_remove),
.enable = sharp_ls_panel_enable,
@@ -220,7 +219,8 @@ static struct omap_dss_driver sharp_ls_driver = {
static int __init sharp_ls_panel_drv_init(void)
{
- return omap_dss_register_driver(sharp_ls_driver);
+ return omap_dss_register_driver_probe(sharp_ls_driver,
+ sharp_ls_panel_probe);
}
static void __exit sharp_ls_panel_drv_exit(void)
diff --git a/drivers/video/omap2/displays/panel-taal.c
b/drivers/video/omap2/displays/panel-taal.c
index 490998f..d62821e 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -661,7 +661,7 @@ static void taal_hw_reset(struct omap_dss_device *dssdev)
msleep(td-panel_config-sleep.hw_reset);
}
-static int taal_probe(struct omap_dss_device *dssdev)
+static int __init taal_probe(struct omap_dss_device *dssdev)
{
struct backlight_properties props;
struct taal_data *td;
@@ -1556,7 +1556,6 @@ static enum omap_dss_update_mode taal_get_update_mode(
}
static struct omap_dss_driver taal_driver = {
- .probe = taal_probe,
.remove = __exit_p(taal_remove),
.enable = taal_enable,
@@ -1593,7 +1592,7 @@ static struct omap_dss_driver taal_driver = {
static int __init taal_init(void)
{
- omap_dss_register_driver(taal_driver);
+ omap_dss_register_driver_probe(taal_driver, taal_probe);
return 0;
}
--
1.7.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
[PATCHv3] omap: rx51: Platform support for lp5523 led chip
Signed-off-by: Ameya Palande ameya.pala...@nokia.com
Signed-off-by: Mathias Nyman mathias.ny...@nokia.com
---
arch/arm/mach-omap2/board-rx51-peripherals.c | 66 ++
1 files changed, 66 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-rx51-peripherals.c
b/arch/arm/mach-omap2/board-rx51-peripherals.c
index bbcb677..d8ec895 100644
--- a/arch/arm/mach-omap2/board-rx51-peripherals.c
+++ b/arch/arm/mach-omap2/board-rx51-peripherals.c
@@ -38,6 +38,7 @@
#include sound/tpa6130a2-plat.h
#include media/radio-si4713.h
#include media/si4713.h
+#include linux/leds-lp5523.h
#include ../drivers/staging/iio/light/tsl2563.h
@@ -51,6 +52,7 @@
#define RX51_WL1251_IRQ_GPIO 42
#define RX51_FMTX_RESET_GPIO 163
#define RX51_FMTX_IRQ 53
+#define RX51_LP5523_CHIP_EN_GPIO 41
/* list all spi devices here */
enum {
@@ -67,6 +69,64 @@ static struct tsl2563_platform_data
rx51_tsl2563_platform_data = {
};
#endif
+#if defined(CONFIG_LEDS_LP5523) || defined(CONFIG_LEDS_LP5523_MODULE)
+static struct lp5523_led_config rx51_lp5523_led_config[] = {
+ {
+ .chan_nr= 0,
+ .led_current= 50,
+ }, {
+ .chan_nr= 1,
+ .led_current= 50,
+ }, {
+ .chan_nr= 2,
+ .led_current= 50,
+ }, {
+ .chan_nr= 3,
+ .led_current= 50,
+ }, {
+ .chan_nr= 4,
+ .led_current= 50,
+ }, {
+ .chan_nr= 5,
+ .led_current= 50,
+ }, {
+ .chan_nr= 6,
+ .led_current= 50,
+ }, {
+ .chan_nr= 7,
+ .led_current= 50,
+ }, {
+ .chan_nr= 8,
+ .led_current= 50,
+ }
+};
+
+static int rx51_lp5523_setup(void)
+{
+ return gpio_request_one(RX51_LP5523_CHIP_EN_GPIO, GPIOF_DIR_OUT,
+ lp5523_enable);
+}
+
+static void rx51_lp5523_release(void)
+{
+ gpio_free(RX51_LP5523_CHIP_EN_GPIO);
+}
+
+static void rx51_lp5523_enable(bool state)
+{
+ gpio_set_value(RX51_LP5523_CHIP_EN_GPIO, !!state);
+}
+
+static struct lp5523_platform_data rx51_lp5523_platform_data = {
+ .led_config = rx51_lp5523_led_config,
+ .num_channels = ARRAY_SIZE(rx51_lp5523_led_config),
+ .clock_mode = LP5523_CLOCK_AUTO,
+ .setup_resources= rx51_lp5523_setup,
+ .release_resources = rx51_lp5523_release,
+ .enable = rx51_lp5523_enable,
+};
+#endif
+
static struct omap2_mcspi_device_config wl1251_mcspi_config = {
.turbo_mode = 0,
.single_channel = 1,
@@ -816,6 +876,12 @@ static struct i2c_board_info __initdata
rx51_peripherals_i2c_board_info_2[] = {
.platform_data = rx51_tsl2563_platform_data,
},
#endif
+#if defined(CONFIG_LEDS_LP5523) || defined(CONFIG_LEDS_LP5523_MODULE)
+ {
+ I2C_BOARD_INFO(lp5523, 0x32),
+ .platform_data = rx51_lp5523_platform_data,
+ },
+#endif
{
I2C_BOARD_INFO(tpa6130a2, 0x60),
.platform_data = rx51_tpa6130a2_data,
--
1.7.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 2.6.39] omap: board-4430sdp: revert hsmmc_info reordering
On Fri, Apr 1, 2011 at 1:50 PM, Luciano Coelho coe...@ti.com wrote: On Fri, 2011-04-01 at 12:46 +0530, Kishore Kadiyala wrote: On Fri, Apr 1, 2011 at 12:22 PM, Luciano Coelho coe...@ti.com wrote: The order in which the MMC cards are defined in the the 4430sdp board file seems to have been mistakenly reorderded as part of an unrelated patch. In commit 0005ae73cfe44ee42d0be12a12cc82bf982f518e, where only the dev_name was supposed to be changed, the mmc order was changed as well. This caused the external SD card reader not to be recognized, at least on Blaze. Both OMAP4 SDP Blaze boards have internal eMMC as storage. Just think of some scenario as below with FS in eMMC [with external card recognized as mmcblk0 and eMMC as mmcblk1]: Booting with both external card on MMC1 and eMMC on MMC2 and having bootargs set to root=/dev/mmcblk1px [x= parition number]. Removing the external card from slot makes eMMC recognized as mmcblk0 and in this case kernel can't pick the file system as passed above in the bootargs. Yes, this makes sense. The internal eMMC should be mapped first, I agree. So, making the permanent storage on the boards registered as first block device gets rid of the problem. Yes, but there is something wrong that causes the external MMC not to be recognized at all if you map the internal MMC first. There is a bug elsewhere that needs to be fixed before this change can be made. As I said, I don't know much about the OMAP MMC subsystem and I don't have the time right now to investigate what really is wrong. That's why I sent this patch, as quick fix (or rather getting rid of a regression). I don't see any regression with 2.6.39-rc1 on either OMAP4430SDP or Blaze, logs below: Blaze log : http://pastebin.com/mGB5uD7P SDP log : http://pastebin.com/A5uAFfsr Another thing is that this is a crosspatch change. It shouldn't be part of the same patch that changes the name of the driver, since this is totally unrelated. If you really think this needs to be done, it should have been done in a separate patch. Agree , it went accidentally in V6. -- Cheers, 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 2.6.39] omap: board-4430sdp: revert hsmmc_info reordering
On Fri, 2011-04-01 at 15:56 +0530, Kishore Kadiyala wrote: As I said, I don't know much about the OMAP MMC subsystem and I don't have the time right now to investigate what really is wrong. That's why I sent this patch, as quick fix (or rather getting rid of a regression). I don't see any regression with 2.6.39-rc1 on either OMAP4430SDP or Blaze, logs below: Blaze log : http://pastebin.com/mGB5uD7P SDP log : http://pastebin.com/A5uAFfsr Hmmm... right. Actually I have now changed rootwait for rootdelay in my kernel parameters and it worked fine with my setup too. This is weird, shouldn't rootwait cause the kernel to wait indefinitely until the root device shows up? -- Cheers, 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: [GIT PULL] omap changes for v2.6.39 merge window
On Friday 01 April 2011, Tomi Valkeinen wrote: On Thu, 2011-03-31 at 17:23 +0200, Arnd Bergmann wrote: * The DSS display drivers introduce new infrastructure include new bus types that have the complexity to make them completely generic, but in practice can only work on OMAP, and are clearly not written with cross-vendor abstractions in mind. If you mean the panel drivers, then I disagree. They are currently OMAP specific, but they are designed so that making them generic shouldn't be too difficult. It's been my aim for a long time already to make the panel drivers generic, but I've never had time and it's never been quite clear to me what would be the best way to do that. The core DSS driver is OMAP specific, and while the DSS IP could in theory be used in some other platform, that is not currently the case and I wouldn't want to needlessly start abstracting things for just the sake of abstracting. Ok, fair enough. I haven't looked at the OMAP DSS code in detail, so I apologise if I did it injustice. What I did review is the ST Ericsson MCDE code which was written by taking the OMAP code as an example. The symptom I'm describing is that infrastructure is getting added to platform specific code without making clear that it is mean to be generic. I.e. the code is hidded away in the drivers/video/omap directory, where other people would not go looking for it. What I would have hoped you to do is to tell the ST Ericsson people when they posted their code that they should instead work with you to integrate the two implementations. As far as I remember (I may be wrong again), that did not happen. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Thursday 31 March 2011, Kevin Hilman wrote: Arnd Bergmann a...@arndb.de writes: But that's the point. The incentive is there for managing the infrastructure within the SoC, but not across SoCs. OK, but the rest of my thread went on to describe how at least a few ARM SoC maintainers are actually actively working infrastructure that is cross SoC, like runtime PM. It might start because of an abstraction within an SoC family like supporting both SH and SH-mobile, or OMAP[12345], but it does sometimes result in not only cross-SoC code but cross-platform frameworks. Admiteddly, the percentage of ARM SoC developers actively working on these common, cross-platform infrastructure layers is rather small, but at least it is non-zero. :) True, I was oversimplifying. Still, the problem exists that to a large degree, infrastructure also gets added to platform specific code where it has no place. With that as background, hwmod was never inteded as something to be cross-SoC. If you look at the data that's in an omap_hwmod, it's entirely OMAP hardware specific, and mostly focused on power management hardware details, register descriptions, feature capabilities etc. This allows the OMAP PM core code to be generalized and work across all SoCs in the OMAP family. But again, it was intended for OMAP PM core code. At that level, there really isn't much to share with other SoCs since the PM hardware for the various SoC vendors is so differentiated (a.k.a fsck'd up in extremely different ways.) There is an important difference between code that knows about board, soc and platform specific issues (drivers) and code that manages these (infrastructure). Obviously, any hardware implementation, broadly speaking, that is different from the other ones needs a driver. However, the infrastructure for managing multiple drivers should be written in a way that works for as many similar drivers as possible. My complaint about the four examples I've given is that they mix the driver with the infrastructure. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Thursday 31 March 2011, Thomas Gleixner wrote: On Thu, 31 Mar 2011, Arnd Bergmann wrote: Right, but the problem starts in way simpler areas like irq chips and gpio stuff, where lots of the IP cores are similar and trivial enough to be shared across many SoC families. Yes, I'm sure that there are more obvious examples than the ones I've given, those were just the ones that I had noticed myself. Even the OMAP consolidated code is silly: But the code above has 6 cases in the switch because nobody abstracted it out consequently. Not to talk about the ifdef mess. Nice illustration. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.39] omap: board-4430sdp: revert hsmmc_info reordering
On Fri, 2011-04-01 at 09:52 +0300, Luciano Coelho wrote: The order in which the MMC cards are defined in the the 4430sdp board file seems to have been mistakenly reorderded as part of an unrelated patch. In commit 0005ae73cfe44ee42d0be12a12cc82bf982f518e, where only the dev_name was supposed to be changed, the mmc order was changed as well. This caused the external SD card reader not to be recognized, at least on Blaze. This patch reverts this change so that the external SD card is recognized again. Cc: Kishore Kadiyala kishore.kadiy...@ti.com Cc: Benoit Cousson b-cous...@ti.com Signed-off-by: Luciano Coelho coe...@ti.com --- Please drop this patch. The problem was not in the order the MMCs were mounted, but something wrong with my bootloader settings where the rootwait was not been passed to the kernel properly. Now it works fine for me too. Sorry for the trouble! -- Cheers, 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: [GIT PULL] omap changes for v2.6.39 merge window
(dropping people from cc, as this is getting quite DSS spesific) On Fri, 2011-04-01 at 13:22 +0200, Arnd Bergmann wrote: On Friday 01 April 2011, Tomi Valkeinen wrote: On Thu, 2011-03-31 at 17:23 +0200, Arnd Bergmann wrote: * The DSS display drivers introduce new infrastructure include new bus types that have the complexity to make them completely generic, but in practice can only work on OMAP, and are clearly not written with cross-vendor abstractions in mind. If you mean the panel drivers, then I disagree. They are currently OMAP specific, but they are designed so that making them generic shouldn't be too difficult. It's been my aim for a long time already to make the panel drivers generic, but I've never had time and it's never been quite clear to me what would be the best way to do that. The core DSS driver is OMAP specific, and while the DSS IP could in theory be used in some other platform, that is not currently the case and I wouldn't want to needlessly start abstracting things for just the sake of abstracting. Ok, fair enough. I haven't looked at the OMAP DSS code in detail, so I apologise if I did it injustice. What I did review is the ST Ericsson MCDE code which was written by taking the OMAP code as an example. The symptom I'm describing is that infrastructure is getting added to platform specific code without making clear that it is mean to be generic. I.e. the code is hidded away in the drivers/video/omap directory, where other people would not go looking for it. What I would have hoped you to do is to tell the ST Ericsson people when they posted their code that they should instead work with you to integrate the two implementations. As far as I remember (I may be wrong again), that did not happen. I don't seem to remember seeing anything from ST Ericsson... While my memory doesn't always serve me well, I would imagine I'd remember if I'd seen code based on my code. Ah, found them from fbdev mail archive. I was rather busy at that period, I didn't really read the mailing lists. I totally agree with you that we should have a common panel interface layer. As I said, I've had it as a target for a long time. And hopefully now that I moved from Nokia to TI I'll finally have time to work on it also. Thanks for pointing me to the MCDE stuff. I doesn't seem to be merged, though. I need to contact them and see if they're still interested in working on the common interface. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Friday 01 April 2011, Tomi Valkeinen wrote: Thanks for pointing me to the MCDE stuff. I doesn't seem to be merged, though. I need to contact them and see if they're still interested in working on the common interface. I pushed back quite hard on some of the aspects there, which probably prevented it from going in so far. If the code is as much based on the OMAP DSS as I think, quite a number of changes are required to both in order to get them into shape for a decent cross-platform layer, but there should not be any fundamental issues. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Fri, 2011-04-01 at 14:07 +0200, Arnd Bergmann wrote: On Friday 01 April 2011, Tomi Valkeinen wrote: Thanks for pointing me to the MCDE stuff. I doesn't seem to be merged, though. I need to contact them and see if they're still interested in working on the common interface. I pushed back quite hard on some of the aspects there, which probably prevented it from going in so far. If the code is as much based on the OMAP DSS as I think, quite a number of changes are required to both in order to get them into shape for a decent cross-platform layer, but there should not be any fundamental issues. I only looked it briefly, but I'm not sure if there's that much code that could be common. But I need to read the mail thread properly. The driver for the display HW on the SoC doesn't probably have anything in common with OMAP one. What could and should be common is the panel side, which was just a single patch in that patch set. Tomi -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Query: Omap temperature sensor driver design
Hello All, I am trying to implement a driver for the OMAP temperature sensor. It is an on chip sensor. The sensor is responsible for reporting the temperature. The sensor has configurable thresholds. The user can configure the thresholds. An interrupt will be generated as soon as there the temperature thresholds are crossed. Two possible approaches for the driver: 1) The entire driver resides in drivers/hwmon directory. The driver containing all the sysfs nodes to be exposed to the user. The interrupt handlers are also part of this driver. The device registration happens in a OMAP arch specific file residing in arch/arm/mach-omap2 directory. 2) The intialization and the interrupt handling done in a separate driver file residing in in arch/arm/mach-omap2 or drivers/misc directory. The device registration happens in a OMAP arch specific file residing in arch/arm/mach-omap2 directory. Only the sysfs nodes will be exposed through a hwmon driver residing in drivers/hwmon. Please suggest the best alternative among the two or if any new design for the requirements is better. -- Regards and Thanks, Keerthy -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Friday 01 April 2011, Ingo Molnar wrote: IMO the right answer is what Linus and Thomas outlined: 1) provide a small number of clean examples and clean abstractions 2) to not pull new crap from that point on 3) do this gradually but consistently I.e. make all your requirements technical and actionable - avoid sweeping, impossible to meet requirements. Do not require people to clean up all of the existing mess straight away (they cannot realistically do it), do not summarily block the flow of patches, but be firm about drawing a line in the sand and be firm about not introducing new mess in a gradually growing list of well-chosen areas of focus. Rinse, repeat. I believe getting to point 1 is the hard part here. There are a lot of things that are wrong with the mach-* (and also plat-*) implementations, and I don't think we have one today that can really serve as an example. Most decisions made in there made a lot of sense when they were introduced, and declaring code that was perfectly acceptable yesterday to be unacceptable crap today is not going to be met with much understanding by the someone who just wants to add support for one more board to 100 already existing ones in the same SoC family. I would actually suggest a different much more radical start: Fork the way that platforms are managed today, and start an alternative way of setting up boards and devices together with the proven ARM core kernel infrastructure, based on these observations (please correct me if some of them they don't make sense): 1. The core arch code is not a problem (Russell does a great job here) 2. The platform specific code contains a lot of crap that doesn't belong there (not enough reviewers to push back on crap) 3. The amount of crap in platform specfic files is growing exponentially, despite the best efforts of a handful of people to clean it up. 4. Having one source file per board does not scale any more. 5. Discoverable hardware would solve this, but is not going to happen in practice. 6. Board firmware would not solve this and is usually not present. 7. Boot loaders can not be trusted to pass valid information 8. Device tree blobs can solve a lot of the problems, and nobody has come up with a better solution. 9. All interesting work is going into a handful of platforms, all of which are ARMv7 based. 10. We do not want to discontinue support for old boards that work fine. 11. Massive changes to existing platforms would cause massive breakage. 12. Supporting many different boards with a single kernel binary is a useful goal. 13. Infrastructure code should be cross-platform, not duplicated across platforms. 14. 32 bit ARM is hitting the wall in the next years (Cortex-A15 is actually adding PAE support, which has failed to solve this on other architectures). 15. We need to solve the platform problem before 64 bit support comes and adds another dimension to the complexity. Based on these assumptions, my preferred strategy would be to a new mach-nocrap directory with a documented set of rules (to be adapted when necessary): * Strictly no crap * No board files * No hardcoded memory maps * No lists of interrupts and GPIOs * All infrastructure added must be portable to all ARMv7 based SoCs. (ARMv6 can be added later) * 64 bit safe code only. * SMP safe code only. * All board specific information must come from a device tree and be run-time detected. * Must use the same device drivers as existing platforms * Should share platform drivers (interrupt controller, gpio, timer, ...) with existing platforms where appropriate. * Code quality takes priority over stability in mach-nocrap, but must not break other platforms. Until we have something working there, I think we should still generally allow new code to the existing platforms, and even new platforms to be added, while trying to keep the quality as high as possible but without changing the rules for them or doing any major treewide reworks. Once the mach-nocrap approach has turned into something usable, we can proceed on three fronts: 1. delete actively maintained boards from the other platforms once they are no longer needed there 2. generalize concepts from mach-nocrap by applying them to all boards, similar to the cleanup work that people have always been doing. 3. gradually make the rules for adding new code in other platforms stricter, up to the point where they are bugfix only. If companies do not 'bother to push upstream', then management will eventually notice negative economic consequences: ... Good points, I fully agree with these. I also think that the SoC companies are actually understanding this nowadays, and that is exactly the reason why we see so much code getting pushed in. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Wednesday 30 March 2011, Russell King - ARM Linux wrote: On Wed, Mar 30, 2011 at 07:06:41PM +0200, Arnd Bergmann wrote: I'm still new to the ARM world, but I think one real problem is the way that all platforms have their own trees with a very flat hierarchy -- a lot of people directly ask Linus to pull their trees, and the main way to sort out conflicts is linux-next. The number of platforms in the ARM arch is still increasing, so I assume that this only gets worse. The reason that we've ended up with a flat heirarchy in terms of developers is down to pressure. There was a time when we had a more structured system, where the sub-tree people submitted their patches to me and the list, they'd be reviewed (mostly and mostly only) by me before being merged into my tree and going upstream from there. As the community grew, it got harder and harder to do decent reviewed of those patches and so the acceptance rate dropped. Eventually we switched to the current arrangement where I'm essentially only concerned about core ARM code, and a few platforms which I have personal interest in (or are contracted to look after.) For the rest I just look at the patches, and send back what feedback I can on them (which is mostly when my mailer turns a line red because it's matched one of my mutt regexps for spotting common mistakes.) Thanks for the background information. This would be no easier if everyone was asking you to pull their trees, as I believe was the case before that. The amount of code getting changed there is too large to get reviewed by a single person, and I believe neither of you really wants the burden to judge if all of the branches are ok (and complain to the authors when they are not). Absolutely right - and the problem is that we still have no one who is willing to step up and do the review. What I was promised at the time was that by giving sub-tree maintainers the loaded pistol, this problem of code quality would in effect be self- correcting. If they make a hash out of it, they'd have to be the ones to fix it themselves. Instead, what's happening is that the _entire_ ARM community, ARM hardware manufacturers and so forth is being blamed here. This is not my impression. A lot of people are pointing out that there are problems, and how they perceive them, but I don't think that anyone really wants to blame the entire community. Even less I believe that people that understand the situation are blaming you personally. Russell, do you think it would help to have an additional ARM platform tree that collects all the changes that impact only the platform code but not the core architecture? I believe that would be a way out, but requires a careful selection of people responsible for it. In particular, I don't think a single person can handle it without good sub-maintainers. It's not that simple, as what happens when we have core ARM code updates which ends up touching every single board file? The result is conflicts between trees, and that could get extremely messy indeed. I believe that conflicts between two trees are really not the issue, we have tools to solve those in multiple ways, e.g. by pulling in such updates from a topic branch into both trees, or by declaring one of the two trees the master that can pull in the other one occasionally in order to resolve the conflicts. To be honest, given the politics, I don't want to be the one stuck in the middle, receiving and endless stream of Linus' complaints about the way the ARM community works, or the board support code. However, inspite of the sub-tree maintainers having the responsibility for their own code I still find myself in the firing line. I think that is partly a perception problem on your side. Understandably, you still identify yourself with all of the code under arch/arm, so if someone says that the ARM architecture code has problems, you take it personally, even though the problems that are cited are almost exclusively for code that you are not responsible for. And I have got to the point of just not giving a damn. I can't change the ARM community (I've tried over the years to get more active review of platform changes and failed - and had it pointed out by folk like Alan Cox, that such a system is impossible due to lack of motivation by, eg, an OMAP person to review a Samsung change.) I think we're actually just getting there. You were not the only one to point out the problem and Linaro was specifically founded to solve this issue, as far as I can tell. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] OMAP4: clockdomain: Follow recommended enable sequence
Hi Paul, snip.. In omap_hwmod.c:_enable(), what do you think about: 1. saving the current idle mode of the clockdomain, 2. forcing the clockdomain to software-supervised wakeup. 3. enabling clocks and waiting for the module as we currently do, then 4. switching the clockdomain's idle mode back to its original state? Seems like that would be a reasonable approach for the short term, at least for drivers that have been converted to PM runtime. Ok, I'll try and get some RFC patches in these lines soon. I tried some of what you were suggesting here and it seems to work well, like you said, for the drivers which are converted to PM runtime. Now the issue seems to be, how do we handle the ones which are *still* using clock framework to enable main clocks and are yet to be converted to PM runtime. One such, MMC, is showing me issues on OMAP4 even at boot and causes a crash. Its a different thing that some of these drivers which use direct clock calls are working by fluke on OMAP4 since the clock framework does not even wait for the modules to become accessible after the clock enable. I know the right way seems to be to get all these drivers converted to PM runtime, but that might take sometime. regards, Rajendra -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Friday 01 April 2011, Detlef Vollmann wrote: On 04/01/11 15:54, Arnd Bergmann wrote: 9. All interesting work is going into a handful of platforms, all of which are ARMv7 based. Define interesting. The ones that are causing the churn that we're talking about. Platforms that have been working forever and only need to get the occasional bug fix are boring, i.e. not the problem. 12. Supporting many different boards with a single kernel binary is a useful goal. Generally not for embedded systems (for me, a mobile PDA/phone is just a small computer with a crappy keyboard, but not an embedded system). True. For embedded, this would not be an important thing to do, but also not hurt. For anything that a user might want to put a new kernel on, this would be helpful though. Based on these assumptions, my preferred strategy would be to a new mach-nocrap directory with a documented set of rules (to be adapted when necessary): * Strictly no crap * No board files Where do you put code that needs to run very early (e.g. pinging the watchdog)? Don't know. I'd hope we can get fast enough to the phase where device drivers get initialized. * No hardcoded memory maps * No lists of interrupts and GPIOs * All infrastructure added must be portable to all ARMv7 based SoCs. (ARMv6 can be added later) * 64 bit safe code only. * SMP safe code only. * All board specific information must come from a device tree and be run-time detected. What do you mean by run-time detected? For powerpc, we currently have the device tree as DTS in the kernel and compile and bundle it together with the kernel. As you wrote above: Discoverable hardware [...] is not going to happen I mean writing if (device_is_compatible(dev, SOMETHING)) do_something(); instead of #ifdef CONFIG_SOMETHING do_something(); #endif The run-time information could come from anywhere (device tree, hardware registers, today one might use the board number), the important point is not to assume that hardware is present just because someone enabled a Kconfig option. I believe that rule is generally accepted today, but we don't always enforce it. * Must use the same device drivers as existing platforms * Should share platform drivers (interrupt controller, gpio, timer, ...) with existing platforms where appropriate. * Code quality takes priority over stability in mach-nocrap, but must not break other platforms. I agree with the general idea, but nailing down the details in a world as diverse as the ARM world will not be easy... Absolutely, I did not claim to have the single solution that everyone else couldn't see. Please see this more as an RFC. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] OMAP2/3: fix the i2c,gpio reset timeouts during boot.
Hi , The patches solve the reset timeouts seen in i2c and gpio modules while booting omap2 and omap3. Baseline: The patches are based on * git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap-2.6.git * master branch. * v2.6.39-rc1 commit (0ce790e) Testing: * build tested omap2plus_defconfig for warnings and errors. none introduced. * boot tested on 2430. * tested for 'core off' in suspend resume on 3430 sdp. core off counters increment after suspend resume. Core off works with below commands, echo 1 /debug/pm_debug/enable_off_mode echo mem /sys/power/state cat /debug/pm_debug/count | grep ^core Dependencies: * need patch OMAP2+: hwmod data: Set hwmod flags to only allow 16-bit accesses to i2c from Andry Green for accessing i2c_sysc. Without this even with this patch, we will see i2c reset timeouts. br , - Avinash Avinash.H.M (2): OMAP2/3: hwmod: fix the i2c-reset timeout during bootup OMAP2/3: hwmod: fix gpio-reset timeouts seen during bootup. arch/arm/mach-omap2/omap_hwmod.c | 59 ++ arch/arm/mach-omap2/omap_hwmod_2420_data.c |5 ++ arch/arm/mach-omap2/omap_hwmod_2430_data.c |6 +++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |7 +++ arch/arm/plat-omap/include/plat/omap_hwmod.h |2 + 5 files changed, 79 insertions(+), 0 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/2] OMAP2/3: hwmod: fix the i2c-reset timeout during bootup
The i2c module has a special reset sequence. The sequence is
- Disable the I2C.
- Write to SOFTRESET bit.
- Enable the I2C.
- Poll on the RESETDONE bit.
This sequence must be followed for i2c reset in omap2, omap3. The sequence is
implemented as a function and the i2c_class is updated with the correct
'reset' pointer.
Cc: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
Signed-off-by: Avinash.H.M avinas...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 59 ++
arch/arm/mach-omap2/omap_hwmod_2420_data.c |1 +
arch/arm/mach-omap2/omap_hwmod_2430_data.c |1 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |1 +
arch/arm/plat-omap/include/plat/omap_hwmod.h |2 +
5 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c b/arch/arm/mach-omap2/omap_hwmod.c
index e034294..f61c9c8 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -156,6 +156,10 @@
/* Name of the OMAP hwmod for the MPU */
#define MPU_INITIATOR_NAME mpu
+/* In register I2C_CON, Bit 15 is the I2C enable bit */
+#define I2C_EN BIT(15)
+#define I2C_CON_OFFSET 0x24
+
/* omap_hwmod_list contains all registered struct omap_hwmods */
static LIST_HEAD(omap_hwmod_list);
@@ -2369,3 +2373,58 @@ int omap_hwmod_no_setup_reset(struct omap_hwmod *oh)
return 0;
}
+
+/**
+ * omap_i2c_reset- reset the omap i2c module.
+ * @oh: struct omap_hwmod *
+ *
+ * The i2c moudle in omap2, omap3 had a special sequence to reset. The
+ * sequence is:
+ * - Disable the I2C.
+ * - Write to SOFTRESET bit.
+ * - Enable the I2C.
+ * - Poll on the RESETDONE bit.
+ * The sequence is implemented in below function. This is called for 2420,
+ * 2430 and omap3.
+ */
+int omap_i2c_reset(struct omap_hwmod *oh)
+{
+ u32 v = 0;
+ int ret = 0, c = 0;
+
+ /* Disable I2C */
+ v = omap_hwmod_read(oh, I2C_CON_OFFSET);
+ v = v ~I2C_EN;
+ omap_hwmod_write(v, oh, I2C_CON_OFFSET);
+
+ /* Write to the SOFTRESET bit */
+ v = oh-_sysc_cache;
+ ret = _set_softreset(oh, v);
+ if (ret)
+ goto err1;
+ _write_sysconfig(v, oh);
+
+ /* Enable I2C */
+ v = omap_hwmod_read(oh, I2C_CON_OFFSET);
+ v |= I2C_EN;
+ omap_hwmod_write(v, oh, I2C_CON_OFFSET);
+
+ /* Poll on RESETDONE bit */
+ omap_test_timeout((omap_hwmod_read(oh,
+ oh-class-sysc-syss_offs)
+SYSS_RESETDONE_MASK),
+ MAX_MODULE_SOFTRESET_WAIT, c);
+
+ if (c == MAX_MODULE_SOFTRESET_WAIT)
+ pr_warning(%s: %s: softreset failed (waited %d usec)\n,
+ __func__, oh-name, MAX_MODULE_SOFTRESET_WAIT);
+ else
+ pr_debug(%s: %s: softreset in %d usec\n, __func__,
+ oh-name, c);
+
+ return 0;
+
+err1:
+ pr_warning(%s: returned error from _set_softreset\n, __func__);
+ return ret;
+}
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 8eb3ce1..82ff5f7 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -1447,6 +1447,7 @@ static struct omap_hwmod_class_sysconfig i2c_sysc = {
static struct omap_hwmod_class i2c_class = {
.name = i2c,
.sysc = i2c_sysc,
+ .reset = omap_i2c_reset,
};
static struct omap_i2c_dev_attr i2c_dev_attr;
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index a860fb5..ce292f0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -1524,6 +1524,7 @@ static struct omap_hwmod_class_sysconfig i2c_sysc = {
static struct omap_hwmod_class i2c_class = {
.name = i2c,
.sysc = i2c_sysc,
+ .reset = omap_i2c_reset,
};
static struct omap_i2c_dev_attr i2c_dev_attr = {
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index b98e2df..c74f972 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1460,6 +1460,7 @@ static struct omap_hwmod omap3xxx_uart4_hwmod = {
static struct omap_hwmod_class i2c_class = {
.name = i2c,
.sysc = i2c_sysc,
+ .reset = omap_i2c_reset,
};
/*
diff --git a/arch/arm/plat-omap/include/plat/omap_hwmod.h
b/arch/arm/plat-omap/include/plat/omap_hwmod.h
index 1adea9c..26b7ad3 100644
--- a/arch/arm/plat-omap/include/plat/omap_hwmod.h
+++ b/arch/arm/plat-omap/include/plat/omap_hwmod.h
@@ -545,6 +545,8 @@ struct omap_hwmod {
};
int omap_hwmod_register(struct omap_hwmod **ohs);
+int omap_i2c_reset(struct omap_hwmod
[PATCH 2/2] OMAP2/3: hwmod: fix gpio-reset timeouts seen during bootup.
GPIO module expects the debounce clocks to be enabled during reset. It doesn't
reset properly and timeouts are seen, if this clock isn't enabled during
reset. Add the HWMOD_CONTROL_OPT_CLKS_IN_RESET flags to the GPIO HWMODs, with
which the debounce clocks are enabled during reset.
Cc: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
Signed-off-by: Avinash.H.M avinas...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2420_data.c |4
arch/arm/mach-omap2/omap_hwmod_2430_data.c |5 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |6 ++
3 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 82ff5f7..e0bda0a 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -1640,6 +1640,7 @@ static struct omap_hwmod_ocp_if *omap2420_gpio1_slaves[]
= {
static struct omap_hwmod omap2420_gpio1_hwmod = {
.name = gpio1,
+ .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs = omap242x_gpio1_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap242x_gpio1_irqs),
.main_clk = gpios_fck,
@@ -1670,6 +1671,7 @@ static struct omap_hwmod_ocp_if *omap2420_gpio2_slaves[]
= {
static struct omap_hwmod omap2420_gpio2_hwmod = {
.name = gpio2,
+ .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs = omap242x_gpio2_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap242x_gpio2_irqs),
.main_clk = gpios_fck,
@@ -1700,6 +1702,7 @@ static struct omap_hwmod_ocp_if *omap2420_gpio3_slaves[]
= {
static struct omap_hwmod omap2420_gpio3_hwmod = {
.name = gpio3,
+ .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs = omap242x_gpio3_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap242x_gpio3_irqs),
.main_clk = gpios_fck,
@@ -1730,6 +1733,7 @@ static struct omap_hwmod_ocp_if *omap2420_gpio4_slaves[]
= {
static struct omap_hwmod omap2420_gpio4_hwmod = {
.name = gpio4,
+ .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs = omap242x_gpio4_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap242x_gpio4_irqs),
.main_clk = gpios_fck,
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index ce292f0..99cd7bd 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -1743,6 +1743,7 @@ static struct omap_hwmod_ocp_if *omap2430_gpio1_slaves[]
= {
static struct omap_hwmod omap2430_gpio1_hwmod = {
.name = gpio1,
+ .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs = omap243x_gpio1_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap243x_gpio1_irqs),
.main_clk = gpios_fck,
@@ -1773,6 +1774,7 @@ static struct omap_hwmod_ocp_if *omap2430_gpio2_slaves[]
= {
static struct omap_hwmod omap2430_gpio2_hwmod = {
.name = gpio2,
+ .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs = omap243x_gpio2_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap243x_gpio2_irqs),
.main_clk = gpios_fck,
@@ -1803,6 +1805,7 @@ static struct omap_hwmod_ocp_if *omap2430_gpio3_slaves[]
= {
static struct omap_hwmod omap2430_gpio3_hwmod = {
.name = gpio3,
+ .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs = omap243x_gpio3_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap243x_gpio3_irqs),
.main_clk = gpios_fck,
@@ -1833,6 +1836,7 @@ static struct omap_hwmod_ocp_if *omap2430_gpio4_slaves[]
= {
static struct omap_hwmod omap2430_gpio4_hwmod = {
.name = gpio4,
+ .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs = omap243x_gpio4_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap243x_gpio4_irqs),
.main_clk = gpios_fck,
@@ -1863,6 +1867,7 @@ static struct omap_hwmod_ocp_if *omap2430_gpio5_slaves[]
= {
static struct omap_hwmod omap2430_gpio5_hwmod = {
.name = gpio5,
+ .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs = omap243x_gpio5_irqs,
.mpu_irqs_cnt = ARRAY_SIZE(omap243x_gpio5_irqs),
.main_clk = gpio5_fck,
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index c74f972..7552b2f 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -2142,6 +2142,7 @@ static struct omap_hwmod_ocp_if *omap3xxx_gpio1_slaves[]
= {
static struct omap_hwmod omap3xxx_gpio1_hwmod = {
.name = gpio1,
+ .flags = HWMOD_CONTROL_OPT_CLKS_IN_RESET,
.mpu_irqs =
Re: [PATCH] OMAP4: clockdomain: Follow recommended enable sequence
On 4/1/2011 8:21 PM, Rajendra Nayak wrote: Hi Paul, snip.. In omap_hwmod.c:_enable(), what do you think about: 1. saving the current idle mode of the clockdomain, 2. forcing the clockdomain to software-supervised wakeup. 3. enabling clocks and waiting for the module as we currently do, then 4. switching the clockdomain's idle mode back to its original state? Seems like that would be a reasonable approach for the short term, at least for drivers that have been converted to PM runtime. Ok, I'll try and get some RFC patches in these lines soon. I tried some of what you were suggesting here and it seems to work well, like you said, for the drivers which are converted to PM runtime. Now the issue seems to be, how do we handle the ones which are *still* using clock framework to enable main clocks and are yet to be converted to PM runtime. One such, MMC, is showing me issues on OMAP4 even at boot and causes a crash. Its a different thing that some of these drivers which use direct clock calls are working by fluke on OMAP4 since the clock framework does not even wait for the modules to become accessible after the clock enable. I know the right way seems to be to get all these drivers converted to PM runtime, but that might take sometime. One way I am able to get this working (atleast MMC) is by preventing the clock domain belonging to MMC module from being programmed into HW_SUP mode. Acceptable hack in the interim while we wait for the MMC driver to be using PM runtime? regards, Rajendra -- 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: [lm-sensors] Query: Omap temperature sensor driver design
On Fri, Apr 01, 2011 at 08:39:43AM -0400, J, KEERTHY wrote: Hello All, I am trying to implement a driver for the OMAP temperature sensor. It is an on chip sensor. The sensor is responsible for reporting the temperature. The sensor has configurable thresholds. The user can configure the thresholds. An interrupt will be generated as soon as there the temperature thresholds are crossed. Two possible approaches for the driver: 1) The entire driver resides in drivers/hwmon directory. The driver containing all the sysfs nodes to be exposed to the user. The interrupt handlers are also part of this driver. The device registration happens in a OMAP arch specific file residing in arch/arm/mach-omap2 directory. 2) The intialization and the interrupt handling done in a separate driver file residing in in arch/arm/mach-omap2 or drivers/misc directory. The device registration happens in a OMAP arch specific file residing in arch/arm/mach-omap2 directory. Only the sysfs nodes will be exposed through a hwmon driver residing in drivers/hwmon. That really depends if it does anything else besides hw monitoring. A hw monitoring driver can support interrupts, and trigger a poll event on an alarm file if it gets one. But it should only perform hw monitoring functionality. If that interrupt triggers other activity, a thermal subsystem driver may be more appropriate. Thanks, Guenter Please suggest the best alternative among the two or if any new design for the requirements is better. -- Regards and Thanks, Keerthy ___ lm-sensors mailing list lm-sens...@lm-sensors.org http://lists.lm-sensors.org/mailman/listinfo/lm-sensors -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
Hi Arnd, On Fri, 2011-04-01 at 14:54 +0100, Arnd Bergmann wrote: I would actually suggest a different much more radical start: Fork the way that platforms are managed today, and start an alternative way of setting up boards and devices together with the proven ARM core kernel infrastructure, based on these observations (please correct me if some of them they don't make sense): 1. The core arch code is not a problem (Russell does a great job here) 2. The platform specific code contains a lot of crap that doesn't belong there (not enough reviewers to push back on crap) 3. The amount of crap in platform specfic files is growing exponentially, despite the best efforts of a handful of people to clean it up. 4. Having one source file per board does not scale any more. 5. Discoverable hardware would solve this, but is not going to happen in practice. 6. Board firmware would not solve this and is usually not present. 7. Boot loaders can not be trusted to pass valid information 8. Device tree blobs can solve a lot of the problems, and nobody has come up with a better solution. Right, so this is directly related to point (5) because in essence FDT is a way to make undiscoverable hardware discoverable by probing the tree. The `it's just data' mantra sums it up nicely. 9. All interesting work is going into a handful of platforms, all of which are ARMv7 based. I think starting out ARMv7-only might make this more manageable but there are still shed loads of pre-v7 chips out there which we should try not to break. 10. We do not want to discontinue support for old boards that work fine. [...] Based on these assumptions, my preferred strategy would be to a new mach-nocrap directory with a documented set of rules (to be adapted when necessary): This is a nice idea, but I don't think it's entirely practical: * Strictly no crap * No board files I don't understand how you can handle `early quirks' without board files. Does this follow on from Linus' suggestion about moving code out of the kernel and into the bootloader? Realistically, I don't think you will ever get away from board files. The trick is probably to make them as small as possible and common to as many boards as possible (like the platforms directory for PowerPC). * No hardcoded memory maps * No lists of interrupts and GPIOs This is largely just data, so should be do-able once this stuff isn't needed at compile-time (which is becoming the case with stuff like dynamic p2v). Will -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Friday 01 April 2011, Detlef Vollmann wrote: On 04/01/11 16:59, Arnd Bergmann wrote: On Friday 01 April 2011, Detlef Vollmann wrote: On 04/01/11 15:54, Arnd Bergmann wrote: 9. All interesting work is going into a handful of platforms, all of which are ARMv7 based. Define interesting. The ones that are causing the churn that we're talking about. Platforms that have been working forever and only need to get the occasional bug fix are boring, i.e. not the problem. In the ARM tree I only know mach-at91. Atmel still introduces new SOCs based on ARM926EJ-S, and that makes perfect sense for lots of applications. I thought new ones were generally Cortex-M3 based. Either way, even if there are exceptions, focusing on ARMv7 at first should give a good representation of the new development. 12. Supporting many different boards with a single kernel binary is a useful goal. Generally not for embedded systems (for me, a mobile PDA/phone is just a small computer with a crappy keyboard, but not an embedded system). True. For embedded, this would not be an important thing to do, but also not hurt. It costs you flash space. Well, the idea was not to force everyone to enable all options. When this is done right, the kernel would not be any bigger. * Strictly no crap * No board files Where do you put code that needs to run very early (e.g. pinging the watchdog)? Don't know. I'd hope we can get fast enough to the phase where device drivers get initialized. Nope, never happened for me :-( (Watchdog timeouts are often 1s or less.) 1s is a long time. Most of the boot process is drivers anyway, so we just need to make sure that the watchdog is early enough. I believe that rule is generally accepted today, but we don't always enforce it. Without device tree, Kconfig option is the only way that really works today (no runtime HW detection, and same board ID with different setups). I believe that has never been an accepted way of doing things, you are supposed to get a new board ID for every new board, hence the name ;-). ARnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Friday 01 April 2011, Will Deacon wrote: 1. The core arch code is not a problem (Russell does a great job here) 2. The platform specific code contains a lot of crap that doesn't belong there (not enough reviewers to push back on crap) 3. The amount of crap in platform specfic files is growing exponentially, despite the best efforts of a handful of people to clean it up. 4. Having one source file per board does not scale any more. 5. Discoverable hardware would solve this, but is not going to happen in practice. 6. Board firmware would not solve this and is usually not present. 7. Boot loaders can not be trusted to pass valid information 8. Device tree blobs can solve a lot of the problems, and nobody has come up with a better solution. Right, so this is directly related to point (5) because in essence FDT is a way to make undiscoverable hardware discoverable by probing the tree. The `it's just data' mantra sums it up nicely. Well, except that because of point 7, device trees are still inferior to having correct and complete information in hardware. 9. All interesting work is going into a handful of platforms, all of which are ARMv7 based. I think starting out ARMv7-only might make this more manageable but there are still shed loads of pre-v7 chips out there which we should try not to break. Yes, see below: the idea is to touch as little of the existing code as possible, at least in the first stages. 10. We do not want to discontinue support for old boards that work fine. [...] Based on these assumptions, my preferred strategy would be to a new mach-nocrap directory with a documented set of rules (to be adapted when necessary): This is a nice idea, but I don't think it's entirely practical: * Strictly no crap * No board files I don't understand how you can handle `early quirks' without board files. Does this follow on from Linus' suggestion about moving code out of the kernel and into the bootloader? There are multiple ways of dealing with this. One way would be to mandate that the boot loader does the quirks, ideally as little as possible. Another option is to have a boot wrapper with board specific code, which gets run between the regular boot loader and the common kernel entry point. We might need such a wrapper anyway to pass the device tree to the kernel. Realistically, I don't think you will ever get away from board files. The trick is probably to make them as small as possible and common to as many boards as possible (like the platforms directory for PowerPC). Perhaps. But we can start out with strict rules and add exceptions later when we run out of options. * No hardcoded memory maps * No lists of interrupts and GPIOs This is largely just data, so should be do-able once this stuff isn't needed at compile-time (which is becoming the case with stuff like dynamic p2v). Right. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/10] omap2+: Remove gptimer_wakekup for now
Kevin, On 4/1/2011 3:39 AM, Kevin Hilman wrote: Tony Lindgrent...@atomide.com writes: This removes the support for setting the wake-up timer for debugging. Later on we can reserve gptimer1 for PM code only and have similar functionality. Signed-off-by: Tony Lindgrent...@atomide.com While we work on an alternative, rather than completely remove this functionality, below is a very small patch (replaces $SUBJECT patch) that will keep the current wakeup-from-suspend timer for PM debug working. Note that GPT1 fs not just used for wakeups from suspend. GPT1 needs to also be the clockevent (at least during idle) so that next-timer interrupts during idle are also programmed for GPT1. Here is what I see as a possible real solution. Let's see if we're on the same page. - GPT1 reserved for special PM wakeup - GPT2 used as high-resolution clockevent (using sys_clk, but stops during idle) - GPT3 (or counter_32k) used as clocksource depending on Kconfig Whenever we're going idle (or suspend), we have to effectively switch the clockevent from GPT2 to GPT1. I assume this is what you have in mind as well. We'll need to dig into the clockevent (and tick broadcast) code to get this to work on UP. On SMP, the C3STOP flag is used to signify that at clockevent will stop during specific power states, so an alternate clockevent is used, but IIUC, this doesn't currently work the same on UP. I think Santosh has looked into this more recently than I have. Santosh, if you have any recent status on this, could you share? I'll gladly work on the clockevent layer if necessary for this. For OMAP4, it's already part of OMAP4 PM series as you know. For OMAP3 as well I had cooked up couple of patches some time back to get clock event switching working. Will find and post them soon. Regards Santosh -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Fri, Apr 1, 2011 at 8:55 AM, Arnd Bergmann a...@arndb.de wrote:
Well, except that because of point 7, device trees are still inferior to
having correct and complete information in hardware.
Oh, absolutely.
If you have discoverable hardware, use it.
But by discoverable hardware I mean something like PCI config
cycles. IOW, real hardware features. Not some code like
if (board_signature_is(xyz)) {
...
that just maps some _other_ hardware knowledge (reading a SoC ID or
something) into an unrelated thing (I know this SoC has these bits of
hardware).
So devicetree should never override actual hardware tells me it
exists here. But you might well have a mapping from SoC ID's to a
compiled-in devicetree thing (this is largely what POWER does, iirc).
Linus
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Fri, Apr 01, 2011 at 05:50:17PM +0200, Arnd Bergmann wrote: On Friday 01 April 2011, Detlef Vollmann wrote: On 04/01/11 16:59, Arnd Bergmann wrote: On Friday 01 April 2011, Detlef Vollmann wrote: On 04/01/11 15:54, Arnd Bergmann wrote: 9. All interesting work is going into a handful of platforms, all of which are ARMv7 based. Define interesting. The ones that are causing the churn that we're talking about. Platforms that have been working forever and only need to get the occasional bug fix are boring, i.e. not the problem. In the ARM tree I only know mach-at91. Atmel still introduces new SOCs based on ARM926EJ-S, and that makes perfect sense for lots of applications. I thought new ones were generally Cortex-M3 based. Either way, even if there are exceptions, focusing on ARMv7 at first should give a good representation of the new development. If they're M3 then they're a microcontroller, and so would be using uclinux. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Fri, 1 Apr 2011, Arnd Bergmann wrote: On Friday 01 April 2011, Detlef Vollmann wrote: On 04/01/11 16:59, Arnd Bergmann wrote: On Friday 01 April 2011, Detlef Vollmann wrote: On 04/01/11 15:54, Arnd Bergmann wrote: 9. All interesting work is going into a handful of platforms, all of which are ARMv7 based. Define interesting. The ones that are causing the churn that we're talking about. Platforms that have been working forever and only need to get the occasional bug fix are boring, i.e. not the problem. In the ARM tree I only know mach-at91. Atmel still introduces new SOCs based on ARM926EJ-S, and that makes perfect sense for lots of applications. I thought new ones were generally Cortex-M3 based. Either way, even if there are exceptions, focusing on ARMv7 at first should give a good representation of the new development. The actual CPU core doesn't matter at all. Whether it is ARM926EJ-S, XScale, PJ4 or Cortex-A8/A9, _that_ is the part that is extremely well maintained and abstracted already. The focus should instead be put on those platforms that are the most used irrespective of their cores. And by selecting the most used platforms, we have a greater chance to create community momentum, and good examples will be spread more quickly. 12. Supporting many different boards with a single kernel binary is a useful goal. Generally not for embedded systems (for me, a mobile PDA/phone is just a small computer with a crappy keyboard, but not an embedded system). True. For embedded, this would not be an important thing to do, but also not hurt. It costs you flash space. Well, the idea was not to force everyone to enable all options. When this is done right, the kernel would not be any bigger. With many SOCs each with their own peculiarities, the kernel would obviously grow bigger. But the major advantage of being _able_ to do that is not ultimately to have only one kernel with multi-board support even if in some context this has great value, but rather to enforce good code reuse and abstraction. Russell suggested that we enable CONFIG_ARM_PATCH_PHYS_VIRT by default. This is already one way to remove one of the most fundamental board specific piece of information that can be deduced at run time instead of having compile time constants per SOC. I however don't think it is practical to go off in a separate mach-nocrap space and do things in parallel. Taking OMAP as an example, there is already way too big of an infrastructure in place to simply rewrite it in parallel to new OMAP versions coming up. It would be more useful and scalable to simply sit down, look at the current mess, and identify common patterns that can be easily factored out into some shared library code, and all that would be left in the board or SOC specific files eventually is the data to register with that library code. Nothing so complicated as grand plans or planification that makes it look like a mountain. Two patterns were identified so far, and they are: 1) GPIO drivers As Linus observed, in the majority of the cases GPIOs are accessed through simple memory-mapped registers. Some have absolute state registers, the others have separate clear/set registers. Suffice to create two generic GPIO drivers each covering those two common cases, and those generic drivers would simply register with the higher level gpiolib code, and all the board code would have to do is to provide the data for those GPIOs (register offsets, number of GPIOs, etc.). Whether this data eventually comes from DT is an orthogonal issue. 2) IRQ chip drivers Again, as Thomas observed, the same issue exists with the majority of the IRQ chip drivers. Most of them follow a common simple pattern that can be abstracted in some generic library code due to their very similar mode of operation. Writing a common driver would leave the board specific code with only a data table describing hardware registers. A good example of such rationalization that already happened is the leds-gpio driver (./drivers/leds/leds-gpio.c), or similarly the gpio-keys driver (drivers/input/keyboard/gpio_keys.c). I remember when those board files were implementing their own simple drivers hooking directly to the input API or the LED API. After that let's take another identified common pattern and factorize it out from board code. That might be timers (see RMK's recent sched_clock() rationalization). That might be clocks (patches from Jeremy Kerr exist and need merged). Etc. Eventually we won't be able to find any more identifiable patterns which are factorisable, and what will be left in board files is only genuine SOC differences. And if all that is left is actually only data tables, then maybe such board files could go entirely and that data be passed via device tree, but that is still a long way off. I
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Fri, 1 Apr 2011, Arnd Bergmann wrote: On Friday 01 April 2011, Will Deacon wrote: 1. The core arch code is not a problem (Russell does a great job here) 2. The platform specific code contains a lot of crap that doesn't belong there (not enough reviewers to push back on crap) 3. The amount of crap in platform specfic files is growing exponentially, despite the best efforts of a handful of people to clean it up. 4. Having one source file per board does not scale any more. 5. Discoverable hardware would solve this, but is not going to happen in practice. 6. Board firmware would not solve this and is usually not present. 7. Boot loaders can not be trusted to pass valid information 8. Device tree blobs can solve a lot of the problems, and nobody has come up with a better solution. Right, so this is directly related to point (5) because in essence FDT is a way to make undiscoverable hardware discoverable by probing the tree. The `it's just data' mantra sums it up nicely. Well, except that because of point 7, device trees are still inferior to having correct and complete information in hardware. I helped with the design of a rather simple patch for ARM allowing for: cat zImage foobar.dtb zImage_with_dtb Then the kernel is smart enough to detect it has a dtb on its tail and use it. In a perfect world the bootloader would be bug free and always up to date with the best DT data. In practice I'm very skeptical this will always be the case and painless. At least the above makes it very simple to have a self contained kernel when (not if) need be. 9. All interesting work is going into a handful of platforms, all of which are ARMv7 based. I think starting out ARMv7-only might make this more manageable but there are still shed loads of pre-v7 chips out there which we should try not to break. Yes, see below: the idea is to touch as little of the existing code as possible, at least in the first stages. I don't think this is a realistic approach. See my previous mail. Once you start identifying concrete and well defined areas that needs cleaning, it is best to come up with solutions that covers as much existing code as possible, validating that the solution is also worth it in the process. The more existing code you may cover with your cleanup, the more likely it will fit future hardware as well. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] OMAP2/3: hwmod: fix the i2c-reset timeout during bootup
Hi
some comments
On Fri, 1 Apr 2011, Avinash.H.M wrote:
The i2c module has a special reset sequence. The sequence is
- Disable the I2C.
- Write to SOFTRESET bit.
- Enable the I2C.
- Poll on the RESETDONE bit.
This sequence must be followed for i2c reset in omap2, omap3. The sequence is
implemented as a function and the i2c_class is updated with the correct
'reset' pointer.
Cc: Rajendra Nayak rna...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Kevin Hilman khil...@ti.com
Signed-off-by: Avinash.H.M avinas...@ti.com
---
arch/arm/mach-omap2/omap_hwmod.c | 59
++
arch/arm/mach-omap2/omap_hwmod_2420_data.c |1 +
arch/arm/mach-omap2/omap_hwmod_2430_data.c |1 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |1 +
arch/arm/plat-omap/include/plat/omap_hwmod.h |2 +
5 files changed, 64 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod.c
b/arch/arm/mach-omap2/omap_hwmod.c
index e034294..f61c9c8 100644
--- a/arch/arm/mach-omap2/omap_hwmod.c
+++ b/arch/arm/mach-omap2/omap_hwmod.c
@@ -156,6 +156,10 @@
/* Name of the OMAP hwmod for the MPU */
#define MPU_INITIATOR_NAME mpu
+/* In register I2C_CON, Bit 15 is the I2C enable bit */
+#define I2C_EN BIT(15)
+#define I2C_CON_OFFSET 0x24
This stuff, along with omap_i2c_reset(), doesn't belong in omap_hwmod.c,
which is common code that is not I2C-specific. Please put it in
mach-omap2/i2c.c instead.
+
/* omap_hwmod_list contains all registered struct omap_hwmods */
static LIST_HEAD(omap_hwmod_list);
@@ -2369,3 +2373,58 @@ int omap_hwmod_no_setup_reset(struct omap_hwmod *oh)
return 0;
}
+
+/**
+ * omap_i2c_reset- reset the omap i2c module.
+ * @oh: struct omap_hwmod *
+ *
+ * The i2c moudle in omap2, omap3 had a special sequence to reset. The
+ * sequence is:
+ * - Disable the I2C.
+ * - Write to SOFTRESET bit.
+ * - Enable the I2C.
+ * - Poll on the RESETDONE bit.
+ * The sequence is implemented in below function. This is called for 2420,
+ * 2430 and omap3.
+ */
+int omap_i2c_reset(struct omap_hwmod *oh)
+{
+ u32 v = 0;
no need to initialize this to 0
+ int ret = 0, c = 0;
no need to initialize ret to 0
+
+ /* Disable I2C */
+ v = omap_hwmod_read(oh, I2C_CON_OFFSET);
+ v = v ~I2C_EN;
+ omap_hwmod_write(v, oh, I2C_CON_OFFSET);
+
+ /* Write to the SOFTRESET bit */
+ v = oh-_sysc_cache;
+ ret = _set_softreset(oh, v);
+ if (ret)
+ goto err1;
+ _write_sysconfig(v, oh);
+
+ /* Enable I2C */
+ v = omap_hwmod_read(oh, I2C_CON_OFFSET);
+ v |= I2C_EN;
+ omap_hwmod_write(v, oh, I2C_CON_OFFSET);
+
+ /* Poll on RESETDONE bit */
+ omap_test_timeout((omap_hwmod_read(oh,
+ oh-class-sysc-syss_offs)
+ SYSS_RESETDONE_MASK),
+ MAX_MODULE_SOFTRESET_WAIT, c);
+
+ if (c == MAX_MODULE_SOFTRESET_WAIT)
+ pr_warning(%s: %s: softreset failed (waited %d usec)\n,
+ __func__, oh-name, MAX_MODULE_SOFTRESET_WAIT);
+ else
+ pr_debug(%s: %s: softreset in %d usec\n, __func__,
+ oh-name, c);
+
+ return 0;
+
+err1:
+ pr_warning(%s: returned error from _set_softreset\n, __func__);
+ return ret;
+}
diff --git a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
index 8eb3ce1..82ff5f7 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2420_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2420_data.c
@@ -1447,6 +1447,7 @@ static struct omap_hwmod_class_sysconfig i2c_sysc = {
static struct omap_hwmod_class i2c_class = {
.name = i2c,
.sysc = i2c_sysc,
+ .reset = omap_i2c_reset,
};
static struct omap_i2c_dev_attr i2c_dev_attr;
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index a860fb5..ce292f0 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -1524,6 +1524,7 @@ static struct omap_hwmod_class_sysconfig i2c_sysc = {
static struct omap_hwmod_class i2c_class = {
.name = i2c,
.sysc = i2c_sysc,
+ .reset = omap_i2c_reset,
};
static struct omap_i2c_dev_attr i2c_dev_attr = {
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index b98e2df..c74f972 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -1460,6 +1460,7 @@ static struct omap_hwmod omap3xxx_uart4_hwmod = {
static struct omap_hwmod_class i2c_class = {
.name = i2c,
.sysc = i2c_sysc,
+ .reset = omap_i2c_reset,
};
/*
diff
[PATCH] OMAP34xx: Add padconfig offsets for GPIOs 126-129
Add OMAP3_CONTROL_PADCONF_GPIOxxx_OFFSET constants for GPIOs 126-129 Signed-off-by: Matthias Kaehlcke matth...@tomtom.com --- arch/arm/mach-omap2/mux34xx.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-omap2/mux34xx.h b/arch/arm/mach-omap2/mux34xx.h index 6543ebf..70d2b8d 100644 --- a/arch/arm/mach-omap2/mux34xx.h +++ b/arch/arm/mach-omap2/mux34xx.h @@ -393,6 +393,10 @@ #define OMAP3_CONTROL_PADCONF_SAD2D_SWAKEUP_OFFSET 0xa1c #define OMAP3_CONTROL_PADCONF_JTAG_RTCK_OFFSET 0xa1e #define OMAP3_CONTROL_PADCONF_JTAG_TDO_OFFSET 0xa20 +#define OMAP3_CONTROL_PADCONF_GPIO127_OFFSET 0xa24 +#define OMAP3_CONTROL_PADCONF_GPIO126_OFFSET 0xa26 +#define OMAP3_CONTROL_PADCONF_GPIO128_OFFSET 0xa28 +#define OMAP3_CONTROL_PADCONF_GPIO129_OFFSET 0xa2a #define OMAP3_CONTROL_PADCONF_MUX_SIZE \ (OMAP3_CONTROL_PADCONF_JTAG_TDO_OFFSET + 0x2) -- 1.7.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: [GIT PULL] omap changes for v2.6.39 merge window
Hello, On Fri, Apr 01, 2011 at 03:54:47PM -0400, Nicolas Pitre wrote: It would be more useful and scalable to simply sit down, look at the current mess, and identify common patterns that can be easily factored out into some shared library code, and all that would be left in the board or SOC specific files eventually is the data to register with that library code. Nothing so complicated as grand plans or planification that makes it look like a mountain. Two patterns were identified so far, and they are: 1) GPIO drivers As Linus observed, in the majority of the cases GPIOs are accessed through simple memory-mapped registers. Some have absolute state registers, the others have separate clear/set registers. Suffice to create two generic GPIO drivers each covering those two common cases, and those generic drivers would simply register with the higher level gpiolib code, and all the board code would have to do is to provide the data for those GPIOs (register offsets, number of GPIOs, etc.). Whether this data eventually comes from DT is an orthogonal issue. 2) IRQ chip drivers Again, as Thomas observed, the same issue exists with the majority of the IRQ chip drivers. Most of them follow a common simple pattern that can be abstracted in some generic library code due to their very similar mode of operation. Writing a common driver would leave the board specific code with only a data table describing hardware registers. A good example of such rationalization that already happened is the leds-gpio driver (./drivers/leds/leds-gpio.c), or similarly the gpio-keys driver (drivers/input/keyboard/gpio_keys.c). I remember when those board files were implementing their own simple drivers hooking directly to the input API or the LED API. After that let's take another identified common pattern and factorize it out from board code. That might be timers (see RMK's recent sched_clock() rationalization). That might be clocks (patches from Jeremy Kerr exist and need merged). Etc. Another one is pwm (git ls-files arch/arm | grep pwm). A general pwm framework was already discussed on lkml and linux-embedded (http://thread.gmane.org/gmane.linux.ports.mips.general/29037/focus=44475); I don't know the details though. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] twl4030-usb: Report correct vbus value for accessory charger adapters1
The twl4030-usb driver exports the status of VBUS as sysfs attribute.
In case an accessory charger adapter (ACA) is connected to the OTG
transceiver the attribute is always 'off', even when the charger
provides VBUS. Added a variable to keep track of the status of VBUS
and report it correctly
Signed-off-by: Matthias Kaehlcke matthias.kaehl...@tomtom.com
---
drivers/usb/otg/twl4030-usb.c |9 -
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/otg/twl4030-usb.c b/drivers/usb/otg/twl4030-usb.c
index e01b073..efeb4d1 100644
--- a/drivers/usb/otg/twl4030-usb.c
+++ b/drivers/usb/otg/twl4030-usb.c
@@ -160,6 +160,7 @@ struct twl4030_usb {
int irq;
u8 linkstat;
+ boolvbus_supplied;
u8 asleep;
boolirq_enabled;
};
@@ -250,6 +251,8 @@ static enum usb_xceiv_events
twl4030_usb_linkstat(struct twl4030_usb *twl)
int status;
int linkstat = USB_EVENT_NONE;
+ twl-vbus_supplied = false;
+
/*
* For ID/VBUS sensing, see manual section 15.4.8 ...
* except when using only battery backup power, two
@@ -265,6 +268,9 @@ static enum usb_xceiv_events
twl4030_usb_linkstat(struct twl4030_usb *twl)
if (status 0)
dev_err(twl-dev, USB link status err %d\n, status);
else if (status (BIT(7) | BIT(2))) {
+ if (status (BIT(7)))
+twl-vbus_supplied = true;
+
if (status BIT(2))
linkstat = USB_EVENT_ID;
else
@@ -484,7 +490,7 @@ static ssize_t twl4030_usb_vbus_show(struct device *dev,
spin_lock_irqsave(twl-lock, flags);
ret = sprintf(buf, %s\n,
- (twl-linkstat == USB_EVENT_VBUS) ? on : off);
+ twl-vbus_supplied ? on : off);
spin_unlock_irqrestore(twl-lock, flags);
return ret;
@@ -608,6 +614,7 @@ static int __devinit twl4030_usb_probe(struct
platform_device *pdev)
twl-otg.set_peripheral = twl4030_set_peripheral;
twl-otg.set_suspend = twl4030_set_suspend;
twl-usb_mode= pdata-usb_mode;
+ twl-vbus_supplied = false;
twl-asleep = 1;
/* init spinlock for workqueue */
--
1.7.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: [GIT PULL] omap changes for v2.6.39 merge window
Arnd Bergmann a...@arndb.de writes: On Friday 01 April 2011, Detlef Vollmann wrote: On 04/01/11 15:54, Arnd Bergmann wrote: 9. All interesting work is going into a handful of platforms, all of which are ARMv7 based. Define interesting. The ones that are causing the churn that we're talking about. Platforms that have been working forever and only need to get the occasional bug fix are boring, i.e. not the problem. I'm not sure I follow the ARMv7-only thinking either. Picking ARMv7 only would be a good way to avoid part of the problem, but IMO, it doesn't really address the root causes. Part of the ugliness of the platform-specific hackery (and the churn to clean some of it up) is precisely due to support for multiple ARM architecture versions, and the various SoCs in a family that use them. For example, linux-omap supports OMAP1 (ARMv5), OMAP2 (ARMv6), OMAP3 (ARMv7) and OMAP4 (ARMv7 SMP), and OMAP2/3/4 in a single binary. Also, since we've only very recently got to the point of being able to support ARMv6 + ARMv7 UP SMP in the same kernel, making a decision now that only ARMv7 is important seems like a step backwards. If the ultimate goal is getting to a point where we have infrastrucure that can be cross-SoC, surely this same infrastrucure should support multiple ARM architecture revisions. The kernel is only part of many open-source projects, and many of these projects are still using older hardware because it's cheap, available and hackable. Supporting ARMv7 only might be a win for those selling new hardware, but not necessarily a win for the broader open-source community. Kevin (obviously not speaking for my new employer) -- 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/2] OMAP2/3: hwmod: fix the i2c-reset timeout during bootup
Hi Avinash, Avinash.H.M avinas...@ti.com writes: The i2c module has a special reset sequence. The sequence is - Disable the I2C. - Write to SOFTRESET bit. - Enable the I2C. - Poll on the RESETDONE bit. Shouldn't the final state be disabled after reset? IOW, Shouldn't the I2C be disabled again after the polling? Also, when reposting, please be sure to Cc the linux-arm-kernel mailing list for patches that are targetted for upstream. Thanks, Kevin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Friday 01 April 2011 23:10:04 Kevin Hilman wrote: Arnd Bergmann a...@arndb.de writes: On Friday 01 April 2011, Detlef Vollmann wrote: On 04/01/11 15:54, Arnd Bergmann wrote: 9. All interesting work is going into a handful of platforms, all of which are ARMv7 based. Define interesting. The ones that are causing the churn that we're talking about. Platforms that have been working forever and only need to get the occasional bug fix are boring, i.e. not the problem. I'm not sure I follow the ARMv7-only thinking either. Picking ARMv7 only would be a good way to avoid part of the problem, but IMO, it doesn't really address the root causes. Part of the ugliness of the platform-specific hackery (and the churn to clean some of it up) is precisely due to support for multiple ARM architecture versions, and the various SoCs in a family that use them. For example, linux-omap supports OMAP1 (ARMv5), OMAP2 (ARMv6), OMAP3 (ARMv7) and OMAP4 (ARMv7 SMP), and OMAP2/3/4 in a single binary. Also, since we've only very recently got to the point of being able to support ARMv6 + ARMv7 UP SMP in the same kernel, making a decision now that only ARMv7 is important seems like a step backwards. If the ultimate goal is getting to a point where we have infrastrucure that can be cross-SoC, surely this same infrastrucure should support multiple ARM architecture revisions. Yes, forget about the ARMv7 part of my proposal, that was not a main point. If we decide to have a new clean platform variant the way I suggested, it would be nice to support all machines in a single kernel binary, and at least v6+v7 is a solved problem. Supporting a second kernel binary up to v5 with the same source is also simple, as would be big-endian/little-endian variants, or thumb2/arm variants. We might not want to do all combinations from the start though, and I would choose ARMv6/v7-thumb2-le simply because that's what Linaro is focusing on. The idea is to start with a clearly defined set, but write the code in a way that makes it possible to extend in other directions. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Friday, 1 April 2011, Arnd Bergmann a...@arndb.de wrote: On Friday 01 April 2011 23:10:04 Kevin Hilman wrote: Arnd Bergmann a...@arndb.de writes: On Friday 01 April 2011, Detlef Vollmann wrote: On 04/01/11 15:54, Arnd Bergmann wrote: 9. All interesting work is going into a handful of platforms, all of which are ARMv7 based. Define interesting. The ones that are causing the churn that we're talking about. Platforms that have been working forever and only need to get the occasional bug fix are boring, i.e. not the problem. I'm not sure I follow the ARMv7-only thinking either. Picking ARMv7 only would be a good way to avoid part of the problem, but IMO, it doesn't really address the root causes. Part of the ugliness of the platform-specific hackery (and the churn to clean some of it up) is precisely due to support for multiple ARM architecture versions, and the various SoCs in a family that use them. For example, linux-omap supports OMAP1 (ARMv5), OMAP2 (ARMv6), OMAP3 (ARMv7) and OMAP4 (ARMv7 SMP), and OMAP2/3/4 in a single binary. Also, since we've only very recently got to the point of being able to support ARMv6 + ARMv7 UP SMP in the same kernel, making a decision now that only ARMv7 is important seems like a step backwards. If the ultimate goal is getting to a point where we have infrastrucure that can be cross-SoC, surely this same infrastrucure should support multiple ARM architecture revisions. Yes, forget about the ARMv7 part of my proposal, that was not a main point. If we decide to have a new clean platform variant the way I suggested, it would be nice to support all machines in a single kernel binary, and at least v6+v7 is a solved problem. Supporting a second kernel binary up to v5 with the same source is also simple, as would be big-endian/little-endian variants, or thumb2/arm variants. We might not want to do all combinations from the start though, and I would choose ARMv6/v7-thumb2-le simply because that's what Linaro is focusing on. The idea is to start with a clearly defined set, but write the code in a way that makes it possible to extend in other directions. Thumb-2 is ARMv7 only. If you want a v6+v7 binary it would need to be compiled to ARM. -- Catalin -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Friday 01 April 2011 21:54:47 Nicolas Pitre wrote: On Fri, 1 Apr 2011, Arnd Bergmann wrote: I thought new ones were generally Cortex-M3 based. Either way, even if there are exceptions, focusing on ARMv7 at first should give a good representation of the new development. The actual CPU core doesn't matter at all. Whether it is ARM926EJ-S, XScale, PJ4 or Cortex-A8/A9, _that_ is the part that is extremely well maintained and abstracted already. The focus should instead be put on those platforms that are the most used irrespective of their cores. And by selecting the most used platforms, we have a greater chance to create community momentum, and good examples will be spread more quickly. Agreed. I however don't think it is practical to go off in a separate mach-nocrap space and do things in parallel. Taking OMAP as an example, there is already way too big of an infrastructure in place to simply rewrite it in parallel to new OMAP versions coming up. It would be more useful and scalable to simply sit down, look at the current mess, and identify common patterns that can be easily factored out into some shared library code, and all that would be left in the board or SOC specific files eventually is the data to register with that library code. Nothing so complicated as grand plans or planification that makes it look like a mountain. This is exactly the question it comes down to. So far, we have focused on cleaning up platforms bit by bit. Given sufficient resources, I'm sure this can work. You assume that continuing on this path is the fastest way to clean up the whole mess, while my suggestion is based on the assumption that we can do better by starting a small fork. I think we can both agree that by equally distributing the workforce to both approaches, we'd be off worse than doing one of them right ;-) Two patterns were identified so far, and they are: 1) GPIO drivers As Linus observed, in the majority of the cases GPIOs are accessed through simple memory-mapped registers. Some have absolute state registers, the others have separate clear/set registers. Suffice to create two generic GPIO drivers each covering those two common cases, and those generic drivers would simply register with the higher level gpiolib code, and all the board code would have to do is to provide the data for those GPIOs (register offsets, number of GPIOs, etc.). Whether this data eventually comes from DT is an orthogonal issue. Yes, this sounds like a great idea, but it's also unrelated to whether we'd do a new platform, or introduce this into the existing platforms. 2) IRQ chip drivers Again, as Thomas observed, the same issue exists with the majority of the IRQ chip drivers. Most of them follow a common simple pattern that can be abstracted in some generic library code due to their very similar mode of operation. Writing a common driver would leave the board specific code with only a data table describing hardware registers. Also sounds really good. I think what is needed here is a bunch of people willing to work on such things, extracting those common patterns, and creating the infrastructure to cover them. Once that is in place then we will be in a position to push back on code submissions that don't use that infrastructure, and be on the lookout for new patterns to emerge. Just with the above I think there is sufficient work to keep us busy for a while. That is true, and I think we will need to do this. But as far as I can tell, the problems that you talk about addressing are a different class from the ones I was thinking of, because they only deal with areas that are already isolated drivers with an existing API. The things that I see as harder to do are where we need to change the way that parts of the platform code interact with each other: * platform specific IOMMU interfaces that need to be migrated to common interfaces * duplicated but slightly different header files in include/mach/ * static platform device definitions that get migrated to device tree definitions. Changing these tree-wide feels like open-heart surgery, and we'd spend much time trying not to break stuff that could better be used to fix other stuff. The example that I have in mind is the time when we had a powerpc and a ppc architecture in parallel, with ppc supporting a lot of hardware that powerpc did not, but all new development getting done on powerpc. This took years longer than we had expected at first, but I still think it was a helpful fork. On ARM, we are in a much better shape in the core code than what arch/ppc was, so there would be no point forking that, but the problem on the platform code is quite similar. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at
[PATCH/RFC 00/13] OMAP: voltage layer cleanup and restructure: part 2
Here is part 2 of the voltage layer cleanup and restrucure. This part focuses on the VC layer cleanups and abstracions, and moves register access functions into PRM code. Some things still needed on top of this series, please let me know if you want to work on any of them: - OMAP4: hard-coded I2C SCLL/SCCH values removed and calculated based on sys_clk - OMAP3: abstract CLKSETUP, VOLTSETUP, VOLTSETUP2 to something that is common with OMAP4 so common VC code can be used. (Vishwa started on this one already, but it needs a common OMAP3/OMAP4 description.) This series is based on part 1, and is also available in the pm-wip/voltdm_b branch of my tree. Kevin Kevin Hilman (13): OMAP3+: add PRM VP functions for checking/clearing VP TX done status OMAP3+ VP: replace transaction done check/clear with VP ops OMAP3+: PRM: add register access functions for VC/VP OMAP3+: voltage: convert to PRM register access functions OMAP3+: VC: cleanup i2c slave address configuration OMAP3+: VC: cleanup PMIC register address configuration OMAP3+: VC bypass: use fields from VC struct instead of PMIC info OMAP3+: VC: cleanup voltage setup time configuration OMAP3+: VC: move on/onlp/ret/off command configuration into common init OMAP3+: VC: abstract out channel configuration OMAP4: PRM: VC: rename I2C configuration register: s/INSTE/MODE/ OMAP3+: voltage domain: move PMIC struct from vdd_info into struct voltagedomain OMAP3+: VC: make I2C config programmable with PMIC-specific settings arch/arm/mach-omap2/omap_twl.c| 32 ++-- arch/arm/mach-omap2/prm2xxx_3xxx.c| 56 ++ arch/arm/mach-omap2/prm2xxx_3xxx.h| 12 ++ arch/arm/mach-omap2/prm44xx.c | 71 +++ arch/arm/mach-omap2/prm44xx.h | 16 ++- arch/arm/mach-omap2/vc.c | 256 - arch/arm/mach-omap2/vc.h | 31 ++- arch/arm/mach-omap2/vc3xxx_data.c | 14 +- arch/arm/mach-omap2/vc44xx_data.c | 18 +- arch/arm/mach-omap2/voltage.c | 60 ++- arch/arm/mach-omap2/voltage.h | 27 ++- arch/arm/mach-omap2/voltagedomains3xxx_data.c | 14 +- arch/arm/mach-omap2/voltagedomains44xx_data.c | 21 ++- arch/arm/mach-omap2/vp.c | 86 - arch/arm/mach-omap2/vp.h | 35 ++-- arch/arm/mach-omap2/vp3xxx_data.c | 20 +- arch/arm/mach-omap2/vp44xx_data.c | 26 +-- 17 files changed, 499 insertions(+), 296 deletions(-) -- 1.7.4 -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC 01/13] OMAP3+: add PRM VP functions for checking/clearing VP TX done status
Add SoC specific PRM VP helper functions for checking and clearing
the VP transaction done status.
Longer term, these events should be handled by the forthcoming PRCM
interrupt handler.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/prm2xxx_3xxx.c | 41 ++
arch/arm/mach-omap2/prm2xxx_3xxx.h |4 +++
arch/arm/mach-omap2/prm44xx.c | 49
arch/arm/mach-omap2/prm44xx.h |4 +++
arch/arm/mach-omap2/vp.h | 33 ++-
arch/arm/mach-omap2/vp3xxx_data.c | 19 ++---
arch/arm/mach-omap2/vp44xx_data.c | 25 ++---
7 files changed, 136 insertions(+), 39 deletions(-)
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c
b/arch/arm/mach-omap2/prm2xxx_3xxx.c
index 051213f..58c5c87 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c
@@ -20,6 +20,8 @@
#include plat/cpu.h
#include plat/prcm.h
+#include vp.h
+
#include prm2xxx_3xxx.h
#include cm2xxx_3xxx.h
#include prm-regbits-24xx.h
@@ -156,3 +158,42 @@ int omap2_prm_deassert_hardreset(s16 prm_mod, u8
rst_shift, u8 st_shift)
return (c == MAX_MODULE_HARDRESET_WAIT) ? -EBUSY : 0;
}
+
+/* PRM VP */
+
+/*
+ * struct omap3_vp - OMAP3 VP register access description.
+ * @tranxdone_status: VP_TRANXDONE_ST bitmask in PRM_IRQSTATUS_MPU reg
+ */
+struct omap3_vp {
+ u32 tranxdone_status;
+};
+
+struct omap3_vp omap3_vp[] = {
+ [OMAP3_VP_VDD_MPU_ID] = {
+ .tranxdone_status = OMAP3430_VP1_TRANXDONE_ST_MASK,
+ },
+ [OMAP3_VP_VDD_CORE_ID] = {
+ .tranxdone_status = OMAP3430_VP2_TRANXDONE_ST_MASK,
+ },
+};
+
+#define MAX_VP_ID ARRAY_SIZE(omap3_vp);
+
+u32 omap3_prm_vp_check_txdone(u8 vp_id)
+{
+ struct omap3_vp *vp = omap3_vp[vp_id];
+ u32 irqstatus;
+
+ irqstatus = omap2_prm_read_mod_reg(OCP_MOD,
+ OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
+ return irqstatus vp-tranxdone_status;
+}
+
+void omap3_prm_vp_clear_txdone(u8 vp_id)
+{
+ struct omap3_vp *vp = omap3_vp[vp_id];
+
+ omap2_prm_write_mod_reg(vp-tranxdone_status,
+ OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
+}
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.h
b/arch/arm/mach-omap2/prm2xxx_3xxx.h
index a1fc62a..5112526 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.h
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.h
@@ -303,6 +303,10 @@ extern int omap2_prm_is_hardreset_asserted(s16 prm_mod, u8
shift);
extern int omap2_prm_assert_hardreset(s16 prm_mod, u8 shift);
extern int omap2_prm_deassert_hardreset(s16 prm_mod, u8 rst_shift, u8
st_shift);
+/* OMAP3-specific VP functions */
+u32 omap3_prm_vp_check_txdone(u8 vp_id);
+void omap3_prm_vp_clear_txdone(u8 vp_id);
+
#endif /* CONFIG_ARCH_OMAP4 */
#endif
diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index a2a04bf..3bb2f61 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -21,6 +21,7 @@
#include plat/cpu.h
#include plat/prcm.h
+#include vp.h
#include prm44xx.h
#include prm-regbits-44xx.h
@@ -193,3 +194,51 @@ void omap4_prm_global_warm_sw_reset(void)
v = omap4_prm_read_inst_reg(OMAP4430_PRM_DEVICE_INST,
OMAP4_RM_RSTCTRL);
}
+
+/* PRM VP */
+
+/*
+ * struct omap4_vp - OMAP4 VP register access description.
+ * @irqstatus_mpu: offset to IRQSTATUS_MPU register for VP
+ * @tranxdone_status: VP_TRANXDONE_ST bitmask in PRM_IRQSTATUS_MPU reg
+ */
+struct omap4_vp {
+ u32 irqstatus_mpu;
+ u32 tranxdone_status;
+};
+
+static struct omap4_vp omap4_vp[] = {
+ [OMAP4_VP_VDD_MPU_ID] = {
+ .irqstatus_mpu = OMAP4_PRM_IRQSTATUS_MPU_2_OFFSET,
+ .tranxdone_status = OMAP4430_VP_MPU_TRANXDONE_ST_MASK,
+ },
+ [OMAP4_VP_VDD_IVA_ID] = {
+ .irqstatus_mpu = OMAP4_PRM_IRQSTATUS_MPU_OFFSET,
+ .tranxdone_status = OMAP4430_VP_IVA_TRANXDONE_ST_MASK,
+ },
+ [OMAP4_VP_VDD_CORE_ID] = {
+ .irqstatus_mpu = OMAP4_PRM_IRQSTATUS_MPU_OFFSET,
+ .tranxdone_status = OMAP4430_VP_CORE_TRANXDONE_ST_MASK,
+ },
+};
+
+u32 omap4_prm_vp_check_txdone(u8 vp_id)
+{
+ struct omap4_vp *vp = omap4_vp[vp_id];
+ u32 irqstatus;
+
+ irqstatus = omap4_prminst_read_inst_reg(OMAP4430_PRM_PARTITION,
+ OMAP4430_PRM_OCP_SOCKET_INST,
+ vp-irqstatus_mpu);
+ return irqstatus vp-tranxdone_status;
+}
+
+void omap4_prm_vp_clear_txdone(u8 vp_id)
+{
+ struct omap4_vp *vp = omap4_vp[vp_id];
+
+ omap4_prminst_write_inst_reg(vp-tranxdone_status,
+OMAP4430_PRM_PARTITION,
+OMAP4430_PRM_OCP_SOCKET_INST,
+vp-irqstatus_mpu);
+};
diff --git
[PATCH/RFC 02/13] OMAP3+ VP: replace transaction done check/clear with VP ops
Replace the VP tranxdone check/clear with helper functions from the
PRM layer.
In the process, remove prm_irqst_* voltage structure fields for IRQ
status checking which are no longer needed.
Since these reads/writes of the IRQ status bits were the only PRM
accesses that were not to VC/VP registers, this allows the rest of the
register accesses in the VC/VP code to use VC/VP specific register
access functions (done in the following patch.)
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/voltage.h |2 --
arch/arm/mach-omap2/voltagedomains3xxx_data.c |4
arch/arm/mach-omap2/voltagedomains44xx_data.c |6 --
arch/arm/mach-omap2/vp.c | 16 +---
4 files changed, 5 insertions(+), 23 deletions(-)
diff --git a/arch/arm/mach-omap2/voltage.h b/arch/arm/mach-omap2/voltage.h
index 65c5b81..a3e7d73 100644
--- a/arch/arm/mach-omap2/voltage.h
+++ b/arch/arm/mach-omap2/voltage.h
@@ -147,8 +147,6 @@ struct omap_vdd_info {
u32 curr_volt;
bool vp_enabled;
- s16 prm_irqst_mod;
- u8 prm_irqst_reg;
u32 (*read_reg) (u16 mod, u8 offset);
void (*write_reg) (u32 val, u16 mod, u8 offset);
int (*volt_scale) (struct voltagedomain *voltdm,
diff --git a/arch/arm/mach-omap2/voltagedomains3xxx_data.c
b/arch/arm/mach-omap2/voltagedomains3xxx_data.c
index 7cb27ec..ad8f05b 100644
--- a/arch/arm/mach-omap2/voltagedomains3xxx_data.c
+++ b/arch/arm/mach-omap2/voltagedomains3xxx_data.c
@@ -38,8 +38,6 @@ static const struct omap_vfsm_instance_data
omap3_vdd1_vfsm_data = {
};
static struct omap_vdd_info omap3_vdd1_info = {
- .prm_irqst_mod = OCP_MOD,
- .prm_irqst_reg = OMAP3_PRM_IRQSTATUS_MPU_OFFSET,
.vp_data = omap3_vp1_data,
.vfsm = omap3_vdd1_vfsm_data,
};
@@ -51,8 +49,6 @@ static const struct omap_vfsm_instance_data
omap3_vdd2_vfsm_data = {
};
static struct omap_vdd_info omap3_vdd2_info = {
- .prm_irqst_mod = OCP_MOD,
- .prm_irqst_reg = OMAP3_PRM_IRQSTATUS_MPU_OFFSET,
.vp_data = omap3_vp2_data,
.vfsm = omap3_vdd2_vfsm_data,
};
diff --git a/arch/arm/mach-omap2/voltagedomains44xx_data.c
b/arch/arm/mach-omap2/voltagedomains44xx_data.c
index a05d90a..43e1d38 100644
--- a/arch/arm/mach-omap2/voltagedomains44xx_data.c
+++ b/arch/arm/mach-omap2/voltagedomains44xx_data.c
@@ -37,8 +37,6 @@ static const struct omap_vfsm_instance_data
omap4_vdd_mpu_vfsm_data = {
};
static struct omap_vdd_info omap4_vdd_mpu_info = {
- .prm_irqst_mod = OMAP4430_PRM_OCP_SOCKET_INST,
- .prm_irqst_reg = OMAP4_PRM_IRQSTATUS_MPU_2_OFFSET,
.vp_data = omap4_vp_mpu_data,
.vfsm = omap4_vdd_mpu_vfsm_data,
};
@@ -48,8 +46,6 @@ static const struct omap_vfsm_instance_data
omap4_vdd_iva_vfsm_data = {
};
static struct omap_vdd_info omap4_vdd_iva_info = {
- .prm_irqst_mod = OMAP4430_PRM_OCP_SOCKET_INST,
- .prm_irqst_reg = OMAP4_PRM_IRQSTATUS_MPU_OFFSET,
.vp_data = omap4_vp_iva_data,
.vfsm = omap4_vdd_iva_vfsm_data,
};
@@ -59,8 +55,6 @@ static const struct omap_vfsm_instance_data
omap4_vdd_core_vfsm_data = {
};
static struct omap_vdd_info omap4_vdd_core_info = {
- .prm_irqst_mod = OMAP4430_PRM_OCP_SOCKET_INST,
- .prm_irqst_reg = OMAP4_PRM_IRQSTATUS_MPU_OFFSET,
.vp_data = omap4_vp_core_data,
.vfsm = omap4_vdd_core_vfsm_data,
};
diff --git a/arch/arm/mach-omap2/vp.c b/arch/arm/mach-omap2/vp.c
index f3503de..113c839 100644
--- a/arch/arm/mach-omap2/vp.c
+++ b/arch/arm/mach-omap2/vp.c
@@ -111,10 +111,8 @@ int omap_vp_forceupdate_scale(struct voltagedomain *voltdm,
* is 3us
*/
while (timeout++ VP_TRANXDONE_TIMEOUT) {
- vdd-write_reg(vp-prm_irqst_data-tranxdone_status,
- vdd-prm_irqst_mod, vdd-prm_irqst_reg);
- if (!(vdd-read_reg(vdd-prm_irqst_mod, vdd-prm_irqst_reg)
- vp-prm_irqst_data-tranxdone_status))
+ vp-vp_common-ops-clear_txdone(vp-id);
+ if (!vp-vp_common-ops-check_txdone(vp-id))
break;
udelay(1);
}
@@ -146,9 +144,7 @@ int omap_vp_forceupdate_scale(struct voltagedomain *voltdm,
* Depends on SMPSWAITTIMEMIN/MAX and voltage change
*/
timeout = 0;
- omap_test_timeout((vdd-read_reg(vdd-prm_irqst_mod,
-vdd-prm_irqst_reg)
- vp-prm_irqst_data-tranxdone_status),
+ omap_test_timeout(vp-vp_common-ops-check_txdone(vp-id),
VP_TRANXDONE_TIMEOUT, timeout);
if (timeout = VP_TRANXDONE_TIMEOUT)
pr_err(%s: vdd_%s TRANXDONE timeout exceeded.
@@ -163,10 +159,8 @@ int omap_vp_forceupdate_scale(struct voltagedomain *voltdm,
*/
timeout = 0;
while (timeout++ VP_TRANXDONE_TIMEOUT) {
-
[PATCH/RFC 03/13] OMAP3+: PRM: add register access functions for VC/VP
On OMAP3+, the voltage controller (VC) and voltage processor (VP) are
inside the PRM. Add some PRM helper functions for register access to
these module registers.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/prm2xxx_3xxx.c | 15 +++
arch/arm/mach-omap2/prm2xxx_3xxx.h |8
arch/arm/mach-omap2/prm44xx.c | 22 ++
arch/arm/mach-omap2/prm44xx.h |8
4 files changed, 53 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.c
b/arch/arm/mach-omap2/prm2xxx_3xxx.c
index 58c5c87..3b83763 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.c
@@ -197,3 +197,18 @@ void omap3_prm_vp_clear_txdone(u8 vp_id)
omap2_prm_write_mod_reg(vp-tranxdone_status,
OCP_MOD, OMAP3_PRM_IRQSTATUS_MPU_OFFSET);
}
+
+u32 omap3_prm_vcvp_read(u8 offset)
+{
+ return omap2_prm_read_mod_reg(OMAP3430_GR_MOD, offset);
+}
+
+void omap3_prm_vcvp_write(u32 val, u8 offset)
+{
+ omap2_prm_write_mod_reg(val, OMAP3430_GR_MOD, offset);
+}
+
+u32 omap3_prm_vcvp_rmw(u32 mask, u32 bits, u8 offset)
+{
+ return omap2_prm_rmw_mod_reg_bits(mask, bits, OMAP3430_GR_MOD, offset);
+}
diff --git a/arch/arm/mach-omap2/prm2xxx_3xxx.h
b/arch/arm/mach-omap2/prm2xxx_3xxx.h
index 5112526..cef533d 100644
--- a/arch/arm/mach-omap2/prm2xxx_3xxx.h
+++ b/arch/arm/mach-omap2/prm2xxx_3xxx.h
@@ -307,7 +307,15 @@ extern int omap2_prm_deassert_hardreset(s16 prm_mod, u8
rst_shift, u8 st_shift);
u32 omap3_prm_vp_check_txdone(u8 vp_id);
void omap3_prm_vp_clear_txdone(u8 vp_id);
+/*
+ * OMAP3 access functions for voltage controller (VC) and
+ * voltage proccessor (VP) in the PRM.
+ */
+extern u32 omap3_prm_vcvp_read(u8 offset);
+extern void omap3_prm_vcvp_write(u32 val, u8 offset);
+extern u32 omap3_prm_vcvp_rmw(u32 mask, u32 bits, u8 offset);
#endif /* CONFIG_ARCH_OMAP4 */
+
#endif
/*
diff --git a/arch/arm/mach-omap2/prm44xx.c b/arch/arm/mach-omap2/prm44xx.c
index 3bb2f61..8a3bba3 100644
--- a/arch/arm/mach-omap2/prm44xx.c
+++ b/arch/arm/mach-omap2/prm44xx.c
@@ -24,6 +24,8 @@
#include vp.h
#include prm44xx.h
#include prm-regbits-44xx.h
+#include prcm44xx.h
+#include prminst44xx.h
/*
* Address offset (in bytes) between the reset control and the reset
@@ -242,3 +244,23 @@ void omap4_prm_vp_clear_txdone(u8 vp_id)
OMAP4430_PRM_OCP_SOCKET_INST,
vp-irqstatus_mpu);
};
+
+u32 omap4_prm_vcvp_read(u8 offset)
+{
+ return omap4_prminst_read_inst_reg(OMAP4430_PRM_PARTITION,
+ OMAP4430_PRM_DEVICE_INST, offset);
+}
+
+void omap4_prm_vcvp_write(u32 val, u8 offset)
+{
+ omap4_prminst_write_inst_reg(val, OMAP4430_PRM_PARTITION,
+OMAP4430_PRM_DEVICE_INST, offset);
+}
+
+u32 omap4_prm_vcvp_rmw(u32 mask, u32 bits, u8 offset)
+{
+ return omap4_prminst_rmw_inst_reg_bits(mask, bits,
+ OMAP4430_PRM_PARTITION,
+ OMAP4430_PRM_DEVICE_INST,
+ offset);
+}
diff --git a/arch/arm/mach-omap2/prm44xx.h b/arch/arm/mach-omap2/prm44xx.h
index e385366..048c8e5 100644
--- a/arch/arm/mach-omap2/prm44xx.h
+++ b/arch/arm/mach-omap2/prm44xx.h
@@ -777,6 +777,14 @@ extern void omap4_prm_global_warm_sw_reset(void);
u32 omap4_prm_vp_check_txdone(u8 vp_id);
void omap4_prm_vp_clear_txdone(u8 vp_id);
+/*
+ * OMAP4 access functions for voltage controller (VC) and
+ * voltage proccessor (VP) in the PRM.
+ */
+extern u32 omap4_prm_vcvp_read(u8 offset);
+extern void omap4_prm_vcvp_write(u32 val, u8 offset);
+extern u32 omap4_prm_vcvp_rmw(u32 mask, u32 bits, u8 offset);
+
# endif
#endif
--
1.7.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC 04/13] OMAP3+: voltage: convert to PRM register access functions
Convert VC/VP register access to use PRM VC/VP accessor functions. In
the process, move the read/write function pointers from vdd_info into
struct voltagedomain.
No functional changes.
Additional cleanup:
- remove prm_mod field from VC/VP data structures, the PRM register
access functions know which PRM module to use.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/vc.c | 69 ++---
arch/arm/mach-omap2/vc.h |2 -
arch/arm/mach-omap2/vc3xxx_data.c |1 -
arch/arm/mach-omap2/vc44xx_data.c |1 -
arch/arm/mach-omap2/voltage.c | 31 +---
arch/arm/mach-omap2/voltage.h |7 ++-
arch/arm/mach-omap2/voltagedomains3xxx_data.c |6 ++
arch/arm/mach-omap2/voltagedomains44xx_data.c |9 +++
arch/arm/mach-omap2/vp.c | 57 ++--
arch/arm/mach-omap2/vp.h |2 -
arch/arm/mach-omap2/vp3xxx_data.c |1 -
arch/arm/mach-omap2/vp44xx_data.c |1 -
12 files changed, 76 insertions(+), 111 deletions(-)
diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index ce328c9..349b5b1 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -37,7 +37,7 @@ int omap_vc_pre_scale(struct voltagedomain *voltdm,
return -ENODATA;
}
- if (!vdd-read_reg || !vdd-write_reg) {
+ if (!voltdm-read || !voltdm-write) {
pr_err(%s: No read/write API for accessing vdd_%s regs\n,
__func__, voltdm-name);
return -EINVAL;
@@ -49,24 +49,22 @@ int omap_vc_pre_scale(struct voltagedomain *voltdm,
volt_data = NULL;
*target_vsel = vdd-pmic_info-uv_to_vsel(target_volt);
- *current_vsel = vdd-read_reg(vdd-vp_data-vp_common-prm_mod,
vdd-vp_data-voltage);
+ *current_vsel = voltdm-read(vdd-vp_data-voltage);
/* Setting the ON voltage to the new target voltage */
- vc_cmdval = vdd-read_reg(vc-common-prm_mod, vc-cmdval_reg);
+ vc_cmdval = voltdm-read(vc-cmdval_reg);
vc_cmdval = ~vc-common-cmd_on_mask;
vc_cmdval |= (*target_vsel vc-common-cmd_on_shift);
- vdd-write_reg(vc_cmdval, vc-common-prm_mod, vc-cmdval_reg);
+ voltdm-write(vc_cmdval, vc-cmdval_reg);
/* Setting vp errorgain based on the voltage */
if (volt_data) {
- vp_errgain_val = vdd-read_reg(vdd-vp_data-vp_common-prm_mod,
- vdd-vp_data-vpconfig);
+ vp_errgain_val = voltdm-read(vdd-vp_data-vpconfig);
vdd-vp_rt_data.vpconfig_errorgain = volt_data-vp_errgain;
vp_errgain_val = ~vp_common-vpconfig_errorgain_mask;
vp_errgain_val |= vdd-vp_rt_data.vpconfig_errorgain
vp_common-vpconfig_errorgain_shift;
- vdd-write_reg(vp_errgain_val, vdd-vp_data-vp_common-prm_mod,
- vdd-vp_data-vpconfig);
+ voltdm-write(vp_errgain_val, vdd-vp_data-vpconfig);
}
return 0;
@@ -111,11 +109,10 @@ int omap_vc_bypass_scale_voltage(struct voltagedomain
*voltdm,
(vdd-pmic_info-i2c_slave_addr
vc-common-slaveaddr_shift);
- vdd-write_reg(vc_bypass_value, vc-common-prm_mod, vc_bypass_val_reg);
- vdd-write_reg(vc_bypass_value | vc_valid, vc-common-prm_mod,
- vc_bypass_val_reg);
+ voltdm-write(vc_bypass_value, vc_bypass_val_reg);
+ voltdm-write(vc_bypass_value | vc_valid, vc_bypass_val_reg);
- vc_bypass_value = vdd-read_reg(vc-common-prm_mod, vc_bypass_val_reg);
+ vc_bypass_value = voltdm-read(vc_bypass_val_reg);
/*
* Loop till the bypass command is acknowledged from the SMPS.
* NOTE: This is legacy code. The loop count and retry count needs
@@ -134,8 +131,7 @@ int omap_vc_bypass_scale_voltage(struct voltagedomain
*voltdm,
loop_cnt = 0;
udelay(10);
}
- vc_bypass_value = vdd-read_reg(vc-common-prm_mod,
- vc_bypass_val_reg);
+ vc_bypass_value = voltdm-read(vc_bypass_val_reg);
}
omap_vc_post_scale(voltdm, target_volt, target_vsel, current_vsel);
@@ -144,18 +140,13 @@ int omap_vc_bypass_scale_voltage(struct voltagedomain
*voltdm,
static void __init omap3_vfsm_init(struct voltagedomain *voltdm)
{
- struct omap_vc_channel *vc = voltdm-vc;
- struct omap_vdd_info *vdd = voltdm-vdd;
-
/*
* Voltage Manager FSM parameters init
* XXX This data should be passed in from the board file
*/
- vdd-write_reg(OMAP3_CLKSETUP, vc-common-prm_mod,
OMAP3_PRM_CLKSETUP_OFFSET);
- vdd-write_reg(OMAP3_VOLTOFFSET,
[PATCH/RFC 05/13] OMAP3+: VC: cleanup i2c slave address configuration
- Add an i2c_slave_address field to the omap_vc_channel
- use VC/VP read/modify/write helper instead of open-coding
- remove smps_sa_shift, use __ffs(mask) for shift value
Special thanks to Shweta Gulati shweta.gul...@ti.com for suggesting
the use of __ffs(x) instead of ffs(x) - 1.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/vc.c | 12 +++-
arch/arm/mach-omap2/vc.h |8 +---
arch/arm/mach-omap2/vc3xxx_data.c |2 --
arch/arm/mach-omap2/vc44xx_data.c |3 ---
4 files changed, 12 insertions(+), 13 deletions(-)
diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index 349b5b1..0824904 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -232,11 +232,13 @@ void __init omap_vc_init_channel(struct voltagedomain
*voltdm)
return;
}
- /* Set up the SMPS_SA(i2c slave address in VC */
- vc_val = voltdm-read(vc-common-smps_sa_reg);
- vc_val = ~vc-smps_sa_mask;
- vc_val |= vdd-pmic_info-i2c_slave_addr vc-smps_sa_shift;
- voltdm-write(vc_val, vc-common-smps_sa_reg);
+ /* get PMIC/board specific settings */
+ vc-i2c_slave_addr = vdd-pmic_info-i2c_slave_addr;
+
+ /* Configure the i2c slave address for this VC */
+ voltdm-rmw(vc-smps_sa_mask,
+ vc-i2c_slave_addr __ffs(vc-smps_sa_mask),
+ vc-common-smps_sa_reg);
/* Setup the VOLRA(pmic reg addr) in VC */
vc_val = voltdm-read(vc-common-smps_volra_reg);
diff --git a/arch/arm/mach-omap2/vc.h b/arch/arm/mach-omap2/vc.h
index 553a5ac..ca8479e 100644
--- a/arch/arm/mach-omap2/vc.h
+++ b/arch/arm/mach-omap2/vc.h
@@ -57,20 +57,22 @@ struct omap_vc_common {
/**
* struct omap_vc_channel - VC per-instance data
* @common: pointer to VC common data for this platform
- * @smps_sa_mask: SA* bitmask in the PRM_VC_SMPS_SA register
+ * @smps_sa_mask: i2c slave address bitmask in the PRM_VC_SMPS_SA register
* @smps_volra_mask: VOLRA* bitmask in the PRM_VC_VOL_RA register
- * @smps_sa_shift: SA* field shift in the PRM_VC_SMPS_SA register
* @smps_volra_shift: VOLRA* field shift in the PRM_VC_VOL_RA register
*
* XXX It is not necessary to have both a *_mask and a *_shift -
* remove one
*/
struct omap_vc_channel {
+ /* channel state */
+ u8 i2c_slave_addr;
+
+ /* register access data */
const struct omap_vc_common *common;
u32 smps_sa_mask;
u32 smps_volra_mask;
u8 cmdval_reg;
- u8 smps_sa_shift;
u8 smps_volra_shift;
};
diff --git a/arch/arm/mach-omap2/vc3xxx_data.c
b/arch/arm/mach-omap2/vc3xxx_data.c
index 6b67203..86be50c 100644
--- a/arch/arm/mach-omap2/vc3xxx_data.c
+++ b/arch/arm/mach-omap2/vc3xxx_data.c
@@ -47,7 +47,6 @@ static struct omap_vc_common omap3_vc_common = {
struct omap_vc_channel omap3_vc_mpu = {
.common = omap3_vc_common,
.cmdval_reg = OMAP3_PRM_VC_CMD_VAL_0_OFFSET,
- .smps_sa_shift = OMAP3430_PRM_VC_SMPS_SA_SA0_SHIFT,
.smps_sa_mask = OMAP3430_PRM_VC_SMPS_SA_SA0_MASK,
.smps_volra_shift = OMAP3430_VOLRA0_SHIFT,
.smps_volra_mask = OMAP3430_VOLRA0_MASK,
@@ -56,7 +55,6 @@ struct omap_vc_channel omap3_vc_mpu = {
struct omap_vc_channel omap3_vc_core = {
.common = omap3_vc_common,
.cmdval_reg = OMAP3_PRM_VC_CMD_VAL_1_OFFSET,
- .smps_sa_shift = OMAP3430_PRM_VC_SMPS_SA_SA1_SHIFT,
.smps_sa_mask = OMAP3430_PRM_VC_SMPS_SA_SA1_MASK,
.smps_volra_shift = OMAP3430_VOLRA1_SHIFT,
.smps_volra_mask = OMAP3430_VOLRA1_MASK,
diff --git a/arch/arm/mach-omap2/vc44xx_data.c
b/arch/arm/mach-omap2/vc44xx_data.c
index e3125a3..af922b4 100644
--- a/arch/arm/mach-omap2/vc44xx_data.c
+++ b/arch/arm/mach-omap2/vc44xx_data.c
@@ -49,7 +49,6 @@ static const struct omap_vc_common omap4_vc_common = {
struct omap_vc_channel omap4_vc_mpu = {
.common = omap4_vc_common,
.cmdval_reg = OMAP4_PRM_VC_VAL_CMD_VDD_MPU_L_OFFSET,
- .smps_sa_shift = OMAP4430_SA_VDD_MPU_L_PRM_VC_SMPS_SA_SHIFT,
.smps_sa_mask = OMAP4430_SA_VDD_MPU_L_PRM_VC_SMPS_SA_MASK,
.smps_volra_shift = OMAP4430_VOLRA_VDD_MPU_L_SHIFT,
.smps_volra_mask = OMAP4430_VOLRA_VDD_MPU_L_MASK,
@@ -58,7 +57,6 @@ struct omap_vc_channel omap4_vc_mpu = {
struct omap_vc_channel omap4_vc_iva = {
.common = omap4_vc_common,
.cmdval_reg = OMAP4_PRM_VC_VAL_CMD_VDD_IVA_L_OFFSET,
- .smps_sa_shift = OMAP4430_SA_VDD_IVA_L_PRM_VC_SMPS_SA_SHIFT,
.smps_sa_mask = OMAP4430_SA_VDD_IVA_L_PRM_VC_SMPS_SA_MASK,
.smps_volra_shift = OMAP4430_VOLRA_VDD_IVA_L_SHIFT,
.smps_volra_mask = OMAP4430_VOLRA_VDD_IVA_L_MASK,
@@ -67,7 +65,6 @@ struct omap_vc_channel omap4_vc_iva = {
struct omap_vc_channel omap4_vc_core = {
.common = omap4_vc_common,
.cmdval_reg = OMAP4_PRM_VC_VAL_CMD_VDD_CORE_L_OFFSET,
- .smps_sa_shift = OMAP4430_SA_VDD_CORE_L_0_6_SHIFT,
.smps_sa_mask =
[PATCH/RFC 06/13] OMAP3+: VC: cleanup PMIC register address configuration
- support both voltage register address and command register address
for each VC channel
- add fields for voltage register address (volra) and command register
address (cmdra) to struct omap_vc_channel
- use VC/VP register access read/modify/write helper
- remove volra_shift field (use __ffs(mask) for shift value)
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/vc.c | 17 -
arch/arm/mach-omap2/vc.h |9 -
arch/arm/mach-omap2/vc3xxx_data.c |5 +++--
arch/arm/mach-omap2/vc44xx_data.c |7 ---
4 files changed, 23 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index 0824904..7829861 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -234,17 +234,24 @@ void __init omap_vc_init_channel(struct voltagedomain
*voltdm)
/* get PMIC/board specific settings */
vc-i2c_slave_addr = vdd-pmic_info-i2c_slave_addr;
+ vc-volt_reg_addr = vdd-pmic_info-volt_reg_addr;
+ vc-cmd_reg_addr = vdd-pmic_info-cmd_reg_addr;
/* Configure the i2c slave address for this VC */
voltdm-rmw(vc-smps_sa_mask,
vc-i2c_slave_addr __ffs(vc-smps_sa_mask),
vc-common-smps_sa_reg);
- /* Setup the VOLRA(pmic reg addr) in VC */
- vc_val = voltdm-read(vc-common-smps_volra_reg);
- vc_val = ~vc-smps_volra_mask;
- vc_val |= vdd-pmic_info-volt_reg_addr vc-smps_volra_shift;
- voltdm-write(vc_val, vc-common-smps_volra_reg);
+ /*
+* Configure the PMIC register addresses.
+*/
+ voltdm-rmw(vc-smps_volra_mask,
+ vc-volt_reg_addr __ffs(vc-smps_volra_mask),
+ vc-common-smps_volra_reg);
+ if (vc-cmd_reg_addr)
+ voltdm-rmw(vc-smps_cmdra_mask,
+ vc-cmd_reg_addr __ffs(vc-smps_cmdra_mask),
+ vc-common-smps_cmdra_reg);
/* Configure the setup times */
vc_val = voltdm-read(vdd-vfsm-voltsetup_reg);
diff --git a/arch/arm/mach-omap2/vc.h b/arch/arm/mach-omap2/vc.h
index ca8479e..72c4ee2 100644
--- a/arch/arm/mach-omap2/vc.h
+++ b/arch/arm/mach-omap2/vc.h
@@ -44,6 +44,7 @@ struct omap_vc_common {
u32 valid;
u8 smps_sa_reg;
u8 smps_volra_reg;
+ u8 smps_cmdra_reg;
u8 bypass_val_reg;
u8 data_shift;
u8 slaveaddr_shift;
@@ -59,21 +60,19 @@ struct omap_vc_common {
* @common: pointer to VC common data for this platform
* @smps_sa_mask: i2c slave address bitmask in the PRM_VC_SMPS_SA register
* @smps_volra_mask: VOLRA* bitmask in the PRM_VC_VOL_RA register
- * @smps_volra_shift: VOLRA* field shift in the PRM_VC_VOL_RA register
- *
- * XXX It is not necessary to have both a *_mask and a *_shift -
- * remove one
*/
struct omap_vc_channel {
/* channel state */
u8 i2c_slave_addr;
+ u8 volt_reg_addr;
+ u8 cmd_reg_addr;
/* register access data */
const struct omap_vc_common *common;
u32 smps_sa_mask;
u32 smps_volra_mask;
+ u32 smps_cmdra_mask;
u8 cmdval_reg;
- u8 smps_volra_shift;
};
extern struct omap_vc_channel omap3_vc_mpu;
diff --git a/arch/arm/mach-omap2/vc3xxx_data.c
b/arch/arm/mach-omap2/vc3xxx_data.c
index 86be50c..df8bd5e 100644
--- a/arch/arm/mach-omap2/vc3xxx_data.c
+++ b/arch/arm/mach-omap2/vc3xxx_data.c
@@ -32,6 +32,7 @@
static struct omap_vc_common omap3_vc_common = {
.smps_sa_reg = OMAP3_PRM_VC_SMPS_SA_OFFSET,
.smps_volra_reg = OMAP3_PRM_VC_SMPS_VOL_RA_OFFSET,
+ .smps_cmdra_reg = OMAP3_PRM_VC_SMPS_CMD_RA_OFFSET,
.bypass_val_reg = OMAP3_PRM_VC_BYPASS_VAL_OFFSET,
.data_shift = OMAP3430_DATA_SHIFT,
.slaveaddr_shift = OMAP3430_SLAVEADDR_SHIFT,
@@ -48,14 +49,14 @@ struct omap_vc_channel omap3_vc_mpu = {
.common = omap3_vc_common,
.cmdval_reg = OMAP3_PRM_VC_CMD_VAL_0_OFFSET,
.smps_sa_mask = OMAP3430_PRM_VC_SMPS_SA_SA0_MASK,
- .smps_volra_shift = OMAP3430_VOLRA0_SHIFT,
.smps_volra_mask = OMAP3430_VOLRA0_MASK,
+ .smps_cmdra_mask = OMAP3430_CMDRA0_MASK,
};
struct omap_vc_channel omap3_vc_core = {
.common = omap3_vc_common,
.cmdval_reg = OMAP3_PRM_VC_CMD_VAL_1_OFFSET,
.smps_sa_mask = OMAP3430_PRM_VC_SMPS_SA_SA1_MASK,
- .smps_volra_shift = OMAP3430_VOLRA1_SHIFT,
.smps_volra_mask = OMAP3430_VOLRA1_MASK,
+ .smps_cmdra_mask = OMAP3430_CMDRA1_MASK,
};
diff --git a/arch/arm/mach-omap2/vc44xx_data.c
b/arch/arm/mach-omap2/vc44xx_data.c
index af922b4..5d104ff 100644
--- a/arch/arm/mach-omap2/vc44xx_data.c
+++ b/arch/arm/mach-omap2/vc44xx_data.c
@@ -33,6 +33,7 @@
static const struct omap_vc_common omap4_vc_common = {
.smps_sa_reg = OMAP4_PRM_VC_SMPS_SA_OFFSET,
.smps_volra_reg = OMAP4_PRM_VC_VAL_SMPS_RA_VOL_OFFSET,
+ .smps_cmdra_reg =
[PATCH/RFC 07/13] OMAP3+: VC bypass: use fields from VC struct instead of PMIC info
The PMIC configurable variables should be isolated to VC initialization.
The rest of the VC functions (like VC bypass) should use the i2c slave address
and voltage register address fields from struct omap_vc_channel.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/vc.c |7 ++-
1 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index 7829861..3fdc3fb 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -91,7 +91,6 @@ int omap_vc_bypass_scale_voltage(struct voltagedomain *voltdm,
unsigned long target_volt)
{
struct omap_vc_channel *vc = voltdm-vc;
- struct omap_vdd_info *vdd = voltdm-vdd;
u32 loop_cnt = 0, retries_cnt = 0;
u32 vc_valid, vc_bypass_val_reg, vc_bypass_value;
u8 target_vsel, current_vsel;
@@ -104,10 +103,8 @@ int omap_vc_bypass_scale_voltage(struct voltagedomain
*voltdm,
vc_valid = vc-common-valid;
vc_bypass_val_reg = vc-common-bypass_val_reg;
vc_bypass_value = (target_vsel vc-common-data_shift) |
- (vdd-pmic_info-volt_reg_addr
- vc-common-regaddr_shift) |
- (vdd-pmic_info-i2c_slave_addr
- vc-common-slaveaddr_shift);
+ (vc-volt_reg_addr vc-common-regaddr_shift) |
+ (vc-i2c_slave_addr vc-common-slaveaddr_shift);
voltdm-write(vc_bypass_value, vc_bypass_val_reg);
voltdm-write(vc_bypass_value | vc_valid, vc_bypass_val_reg);
--
1.7.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH/RFC 10/13] OMAP3+: VC: abstract out channel configuration
VC channel configuration is programmed based on settings coming from
the PMIC configuration.
Currently, the VC channel to PMIC mapping is a simple one-to-one
mapping. Whenever a VC channel parameter is configured (i2c slave
addres, PMIC register address, on/ret/off command), the corresponding
bits are enabled in the VC channel configuration register.
If necessary, the programmability of channel configuration settings
could be extended to board/PMIC files, however, because this patch
changes the channel configuration to be programmed based on existing
values from the PMIC settings, it may not be required.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/vc.c | 71 ++--
arch/arm/mach-omap2/vc.h |3 ++
arch/arm/mach-omap2/vc3xxx_data.c |3 ++
arch/arm/mach-omap2/vc44xx_data.c |4 ++
4 files changed, 69 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index 4114909..1ce7b24 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -10,6 +10,53 @@
#include prm-regbits-44xx.h
#include prm44xx.h
+/*
+ * Channel configuration bits, common for OMAP3 4
+ * OMAP3 register: PRM_VC_CH_CONF
+ * OMAP4 register: PRM_VC_CFG_CHANNEL
+ */
+#define CFG_CHANNEL_SABIT(0)
+#define CFG_CHANNEL_RAV BIT(1)
+#define CFG_CHANNEL_RAC BIT(2)
+#define CFG_CHANNEL_RACEN BIT(3)
+#define CFG_CHANNEL_CMD BIT(4)
+#define CFG_CHANNEL_MASK 0x3f
+
+/**
+ * omap_vc_config_channel - configure VC channel to PMIC mappings
+ * @voltdm: pointer to voltagdomain defining the desired VC channel
+ *
+ * Configures the VC channel to PMIC mappings for the following
+ * PMIC settings
+ * - i2c slave address (SA)
+ * - voltage configuration address (RAV)
+ * - command configuration address (RAC) and enable bit (RACEN)
+ * - command values for ON, ONLP, RET and OFF (CMD)
+ *
+ * This function currently only allows flexible configuration of
+ * the non-default channel (e.g. non-zero channels.) Starting with
+ * OMAP4, only the non-zero channels can be configured. Channel zero
+ * always uses the channel zero register values. Therefore, the
+ * same limitation is imposed on OMAP3 for consistency.
+ */
+static int omap_vc_config_channel(struct voltagedomain *voltdm)
+{
+ struct omap_vc_channel *vc = voltdm-vc;
+
+ /*
+* For channel zero, the only configurable bit is RACEN.
+* All others must stay at zero (see function comment above.)
+*/
+ if (!vc-cfg_channel_sa_shift)
+ vc-cfg_channel = CFG_CHANNEL_RACEN;
+
+ voltdm-rmw(CFG_CHANNEL_MASK vc-cfg_channel_sa_shift,
+ vc-cfg_channel vc-cfg_channel_sa_shift,
+ vc-common-cfg_channel_reg);
+
+ return 0;
+}
+
/* Voltage scale and accessory APIs */
int omap_vc_pre_scale(struct voltagedomain *voltdm,
unsigned long target_volt,
@@ -157,8 +204,6 @@ static void __init omap3_vc_init_channel(struct
voltagedomain *voltdm)
* Generic VC parameters init
* XXX This data should be abstracted out
*/
- voltdm-write(OMAP3430_CMD1_MASK | OMAP3430_RAV1_MASK,
- OMAP3_PRM_VC_CH_CONF_OFFSET);
voltdm-write(OMAP3430_MCODE_SHIFT | OMAP3430_HSEN_MASK,
OMAP3_PRM_VC_I2C_CFG_OFFSET);
@@ -177,15 +222,6 @@ static void __init omap4_vc_init_channel(struct
voltagedomain *voltdm)
if (is_initialized)
return;
- /*
-* Generic VC parameters init
-* XXX This data should be abstracted out
-*/
- vc_val = (OMAP4430_RAV_VDD_MPU_L_MASK | OMAP4430_CMD_VDD_MPU_L_MASK |
- OMAP4430_RAV_VDD_IVA_L_MASK | OMAP4430_CMD_VDD_IVA_L_MASK |
- OMAP4430_RAV_VDD_CORE_L_MASK | OMAP4430_CMD_VDD_CORE_L_MASK);
- voltdm-write(vc_val, OMAP4_PRM_VC_CFG_CHANNEL_OFFSET);
-
/* XXX These are magic numbers and do not belong! */
vc_val = (0x60 OMAP4430_SCLL_SHIFT | 0x26 OMAP4430_SCLH_SHIFT);
voltdm-write(vc_val, OMAP4_PRM_VC_CFG_I2C_CLK_OFFSET);
@@ -213,6 +249,8 @@ void __init omap_vc_init_channel(struct voltagedomain
*voltdm)
return;
}
+ vc-cfg_channel = 0;
+
/* get PMIC/board specific settings */
vc-i2c_slave_addr = vdd-pmic_info-i2c_slave_addr;
vc-volt_reg_addr = vdd-pmic_info-volt_reg_addr;
@@ -223,6 +261,7 @@ void __init omap_vc_init_channel(struct voltagedomain
*voltdm)
voltdm-rmw(vc-smps_sa_mask,
vc-i2c_slave_addr __ffs(vc-smps_sa_mask),
vc-common-smps_sa_reg);
+ vc-cfg_channel |= CFG_CHANNEL_SA;
/*
* Configure the PMIC register addresses.
@@ -230,10 +269,14 @@ void __init omap_vc_init_channel(struct voltagedomain
*voltdm)
voltdm-rmw(vc-smps_volra_mask,
vc-volt_reg_addr __ffs(vc-smps_volra_mask),
[PATCH/RFC 13/13] OMAP3+: VC: make I2C config programmable with PMIC-specific settings
Remove hard-coded I2C configuration in favor of settings that can be
configured from PMIC-specific values. Currently only high-speed mode
and the master-code value are supported, since they were the only
fields currently used, but extending this is now trivial.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/omap_twl.c|4 +++
arch/arm/mach-omap2/vc.c | 51 +++-
arch/arm/mach-omap2/vc.h |8 +-
arch/arm/mach-omap2/vc3xxx_data.c |3 ++
arch/arm/mach-omap2/vc44xx_data.c |3 ++
arch/arm/mach-omap2/voltage.h |4 +++
6 files changed, 65 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index feefd30..30f4323 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -159,6 +159,7 @@ static struct omap_voltdm_pmic omap3_mpu_pmic = {
.vp_timeout_us = OMAP3_VP_VLIMITTO_TIMEOUT_US,
.i2c_slave_addr = OMAP3_SRI2C_SLAVE_ADDR,
.volt_reg_addr = OMAP3_VDD_MPU_SR_CONTROL_REG,
+ .i2c_high_speed = true,
.vsel_to_uv = twl4030_vsel_to_uv,
.uv_to_vsel = twl4030_uv_to_vsel,
};
@@ -179,6 +180,7 @@ static struct omap_voltdm_pmic omap3_core_pmic = {
.vp_timeout_us = OMAP3_VP_VLIMITTO_TIMEOUT_US,
.i2c_slave_addr = OMAP3_SRI2C_SLAVE_ADDR,
.volt_reg_addr = OMAP3_VDD_CORE_SR_CONTROL_REG,
+ .i2c_high_speed = true,
.vsel_to_uv = twl4030_vsel_to_uv,
.uv_to_vsel = twl4030_uv_to_vsel,
};
@@ -199,6 +201,7 @@ static struct omap_voltdm_pmic omap4_mpu_pmic = {
.vp_timeout_us = OMAP4_VP_VLIMITTO_TIMEOUT_US,
.i2c_slave_addr = OMAP4_SRI2C_SLAVE_ADDR,
.volt_reg_addr = OMAP4_VDD_MPU_SR_VOLT_REG,
+ .i2c_high_speed = true,
.vsel_to_uv = twl6030_vsel_to_uv,
.uv_to_vsel = twl6030_uv_to_vsel,
};
@@ -219,6 +222,7 @@ static struct omap_voltdm_pmic omap4_iva_pmic = {
.vp_timeout_us = OMAP4_VP_VLIMITTO_TIMEOUT_US,
.i2c_slave_addr = OMAP4_SRI2C_SLAVE_ADDR,
.volt_reg_addr = OMAP4_VDD_IVA_SR_VOLT_REG,
+ .i2c_high_speed = true,
.vsel_to_uv = twl6030_vsel_to_uv,
.uv_to_vsel = twl6030_uv_to_vsel,
};
diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index 910d02f..f8cdb87 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -200,13 +200,6 @@ static void __init omap3_vc_init_channel(struct
voltagedomain *voltdm)
if (is_initialized)
return;
- /*
-* Generic VC parameters init
-* XXX This data should be abstracted out
-*/
- voltdm-write(OMAP3430_MCODE_SHIFT | OMAP3430_HSEN_MASK,
- OMAP3_PRM_VC_I2C_CFG_OFFSET);
-
omap3_vfsm_init(voltdm);
is_initialized = true;
@@ -229,6 +222,48 @@ static void __init omap4_vc_init_channel(struct
voltagedomain *voltdm)
is_initialized = true;
}
+/**
+ * omap_vc_i2c_init - initialize I2C interface to PMIC
+ * @voltdm: voltage domain containing VC data
+ *
+ * Use PMIC supplied seetings for I2C high-speed mode and
+ * master code (if set) and program the VC I2C configuration
+ * register.
+ *
+ * The VC I2C configuration is common to all VC channels,
+ * so this function only configures I2C for the first VC
+ * channel registers. All other VC channels will use the
+ * same configuration.
+ */
+void __init omap_vc_i2c_init(struct voltagedomain *voltdm)
+{
+ struct omap_vc_channel *vc = voltdm-vc;
+ static bool initialized;
+ static bool i2c_high_speed;
+ u8 mcode;
+
+ if (initialized) {
+ if (voltdm-pmic-i2c_high_speed != i2c_high_speed)
+ pr_warn(%s: I2C config for all channels must match.,
+ __func__);
+ return;
+ }
+
+ i2c_high_speed = voltdm-pmic-i2c_high_speed;
+ if (i2c_high_speed)
+ voltdm-rmw(vc-common-i2c_cfg_hsen_shift,
+ vc-common-i2c_cfg_hsen_shift,
+ vc-common-i2c_cfg_reg);
+
+ mcode = voltdm-pmic-i2c_mcode;
+ if (mcode)
+ voltdm-rmw(vc-common-i2c_mcode_mask,
+ mcode __ffs(vc-common-i2c_mcode_mask),
+ vc-common-i2c_cfg_reg);
+
+ initialized = true;
+}
+
void __init omap_vc_init_channel(struct voltagedomain *voltdm)
{
struct omap_vc_channel *vc = voltdm-vc;
@@ -297,6 +332,8 @@ void __init omap_vc_init_channel(struct voltagedomain
*voltdm)
vc-setup_time __ffs(voltdm-vfsm-voltsetup_mask),
voltdm-vfsm-voltsetup_reg);
+ omap_vc_i2c_init(voltdm);
+
if
[PATCH/RFC 12/13] OMAP3+: voltage domain: move PMIC struct from vdd_info into struct voltagedomain
Move structure containing PMIC configurable settings into struct
voltagedomain. In the process, rename from omap_volt_pmic_info to
omap_voltdm_pmic (_info suffix is not helpful.)
No functional changes.
Signed-off-by: Kevin Hilman khil...@ti.com
---
arch/arm/mach-omap2/omap_twl.c | 28 ++--
arch/arm/mach-omap2/vc.c | 29 ++---
arch/arm/mach-omap2/voltage.c | 29 -
arch/arm/mach-omap2/voltage.h | 12 ++--
arch/arm/mach-omap2/vp.c | 13 ++---
5 files changed, 52 insertions(+), 59 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_twl.c b/arch/arm/mach-omap2/omap_twl.c
index 9428b00..feefd30 100644
--- a/arch/arm/mach-omap2/omap_twl.c
+++ b/arch/arm/mach-omap2/omap_twl.c
@@ -143,7 +143,7 @@ static u8 twl6030_uv_to_vsel(unsigned long uv)
return DIV_ROUND_UP(uv - 60, 12500) + 1;
}
-static struct omap_volt_pmic_info omap3_mpu_volt_info = {
+static struct omap_voltdm_pmic omap3_mpu_pmic = {
.slew_rate = 4000,
.step_size = 12500,
.on_volt= 120,
@@ -163,7 +163,7 @@ static struct omap_volt_pmic_info omap3_mpu_volt_info = {
.uv_to_vsel = twl4030_uv_to_vsel,
};
-static struct omap_volt_pmic_info omap3_core_volt_info = {
+static struct omap_voltdm_pmic omap3_core_pmic = {
.slew_rate = 4000,
.step_size = 12500,
.on_volt= 120,
@@ -183,7 +183,7 @@ static struct omap_volt_pmic_info omap3_core_volt_info = {
.uv_to_vsel = twl4030_uv_to_vsel,
};
-static struct omap_volt_pmic_info omap4_mpu_volt_info = {
+static struct omap_voltdm_pmic omap4_mpu_pmic = {
.slew_rate = 4000,
.step_size = 12500,
.on_volt= 135,
@@ -203,7 +203,7 @@ static struct omap_volt_pmic_info omap4_mpu_volt_info = {
.uv_to_vsel = twl6030_uv_to_vsel,
};
-static struct omap_volt_pmic_info omap4_iva_volt_info = {
+static struct omap_voltdm_pmic omap4_iva_pmic = {
.slew_rate = 4000,
.step_size = 12500,
.on_volt= 110,
@@ -223,7 +223,7 @@ static struct omap_volt_pmic_info omap4_iva_volt_info = {
.uv_to_vsel = twl6030_uv_to_vsel,
};
-static struct omap_volt_pmic_info omap4_core_volt_info = {
+static struct omap_voltdm_pmic omap4_core_pmic = {
.slew_rate = 4000,
.step_size = 12500,
.on_volt= 110,
@@ -251,13 +251,13 @@ int __init omap4_twl_init(void)
return -ENODEV;
voltdm = voltdm_lookup(mpu);
- omap_voltage_register_pmic(voltdm, omap4_mpu_volt_info);
+ omap_voltage_register_pmic(voltdm, omap4_mpu_pmic);
voltdm = voltdm_lookup(iva);
- omap_voltage_register_pmic(voltdm, omap4_iva_volt_info);
+ omap_voltage_register_pmic(voltdm, omap4_iva_pmic);
voltdm = voltdm_lookup(core);
- omap_voltage_register_pmic(voltdm, omap4_core_volt_info);
+ omap_voltage_register_pmic(voltdm, omap4_core_pmic);
return 0;
}
@@ -270,10 +270,10 @@ int __init omap3_twl_init(void)
return -ENODEV;
if (cpu_is_omap3630()) {
- omap3_mpu_volt_info.vp_vddmin = OMAP3630_VP1_VLIMITTO_VDDMIN;
- omap3_mpu_volt_info.vp_vddmax = OMAP3630_VP1_VLIMITTO_VDDMAX;
- omap3_core_volt_info.vp_vddmin = OMAP3630_VP2_VLIMITTO_VDDMIN;
- omap3_core_volt_info.vp_vddmax = OMAP3630_VP2_VLIMITTO_VDDMAX;
+ omap3_mpu_pmic.vp_vddmin = OMAP3630_VP1_VLIMITTO_VDDMIN;
+ omap3_mpu_pmic.vp_vddmax = OMAP3630_VP1_VLIMITTO_VDDMAX;
+ omap3_core_pmic.vp_vddmin = OMAP3630_VP2_VLIMITTO_VDDMIN;
+ omap3_core_pmic.vp_vddmax = OMAP3630_VP2_VLIMITTO_VDDMAX;
}
/*
@@ -289,10 +289,10 @@ int __init omap3_twl_init(void)
omap3_twl_set_sr_bit(true);
voltdm = voltdm_lookup(mpu_iva);
- omap_voltage_register_pmic(voltdm, omap3_mpu_volt_info);
+ omap_voltage_register_pmic(voltdm, omap3_mpu_pmic);
voltdm = voltdm_lookup(core);
- omap_voltage_register_pmic(voltdm, omap3_core_volt_info);
+ omap_voltage_register_pmic(voltdm, omap3_core_pmic);
return 0;
}
diff --git a/arch/arm/mach-omap2/vc.c b/arch/arm/mach-omap2/vc.c
index 1ce7b24..910d02f 100644
--- a/arch/arm/mach-omap2/vc.c
+++ b/arch/arm/mach-omap2/vc.c
@@ -71,13 +71,13 @@ int omap_vc_pre_scale(struct voltagedomain *voltdm,
vp_common = vdd-vp_data-vp_common;
/* Check if sufficient pmic info is available for this vdd */
- if (!vdd-pmic_info) {
+ if (!voltdm-pmic) {
pr_err(%s: Insufficient pmic info to scale the vdd_%s\n,
__func__, voltdm-name);
Re: [RFC][PATCH 1/3] OMAP PM: Seggregate Voltage layer parameters
Hi Vishwa,
Vishwanath BS vishwanath...@ti.com writes:
Voltage layer takes various parameters which can be broadly classified as
1. OMAP/VP specific parameters
2. PMIC specific parameters
3. Board specific parameters
This patch attempts to categorize the parameters in current voltage layer into
above buckets. This will make voltage layer to work with different kinds of
PMIC
and boards.
TODO: Provide infrastructure to use VC I2C (I2C4) for PMIC configuration
(useful
for cases where PMIC is connected to OMAP only via I2C4.
Signed-off-by: Vishwanath BS vishwanath...@ti.com
Looking back at this in light of the voltage layer cleanup/restructure
I've been working on, and I have a few more comments/questions.
First, I'm glad to see the various hard-coded setup times cleaned up and
made configuable. Can you redo this on top of the voltage layer
cleanups in progress (my pm-wip/voltdm_b branch)? More details on this
below...
[...]
@@ -44,6 +54,15 @@ struct omap_volt_data omap34xx_vddmpu_volt_data[] = {
VOLT_DATA_DEFINE(0, 0, 0, 0),
};
+struct omap_vp_param omap34xx_mpu_vp_data = {
+ .on_volt= OMAP3_ON_VOLTAGE_UV,
+ .onlp_volt = OMAP3_ONLP_VOLTAGE_UV,
+ .ret_volt = OMAP3_RET_VOLTAGE_UV,
+ .off_volt = OMAP3_OFF_VOLTAGE_UV,
+ .vp_vddmin = OMAP3430_VP1_VLIMITTO_VDDMIN,
+ .vp_vddmax = OMAP3430_VP1_VLIMITTO_VDDMAX,
+};
+
I'm glad to see these removed from the PMIC structure since they are not
PMIC-specific, but the _volt fields in this structure are written to the
VC, not the VP, so should not be part of a VP structure.
[...]
@@ -523,15 +523,35 @@ static int vp_forceupdate_scale_voltage(struct
omap_vdd_info *vdd,
static void __init omap3_vfsm_init(struct omap_vdd_info *vdd)
{
+ struct clk *omap_32k_clk;
+ u32 omap_32k_clk_speed;
+ unsigned long temp;
+
/*
* Voltage Manager FSM parameters init
- * XXX This data should be passed in from the board file
*/
- vdd-write_reg(OMAP3_CLKSETUP, prm_mod_offs, OMAP3_PRM_CLKSETUP_OFFSET);
- vdd-write_reg(OMAP3_VOLTOFFSET, prm_mod_offs,
-OMAP3_PRM_VOLTOFFSET_OFFSET);
- vdd-write_reg(OMAP3_VOLTSETUP2, prm_mod_offs,
-OMAP3_PRM_VOLTSETUP2_OFFSET);
+
+ omap_32k_clk = clk_get(NULL, wkup_32k_fck);
+ if (IS_ERR(omap_32k_clk)) {
+ pr_warning(%s: Could not get the 32k_clk clk to calculate
+ various vdd_%s params\n, __func__, vdd-voltdm.name);
+ return;
+ }
+ omap_32k_clk_speed = clk_get_rate(omap_32k_clk);
+ clk_put(omap_32k_clk);
You probably don't need to do a clk_get/clk_get_rate/clk_put of the 32k
clock, since we know what the rate of that clock is already. :)
IOW, 'omap_32k_clk_speed = (32 10)' should suffice.
+ temp = vdd-board_data-omap3_board_data.vdd_setup_off.clksetup;
+ temp = temp * omap_32k_clk_speed / (1000 * 1000) + 1;
+ vdd-write_reg(temp, prm_mod_offs, OMAP3_PRM_CLKSETUP_OFFSET);
+
+ temp = vdd-board_data-omap3_board_data.vdd_setup_off.voltsetup2;
+ temp = temp * omap_32k_clk_speed / (1000 * 1000) + 1;
+ vdd-write_reg(temp, prm_mod_offs, OMAP3_PRM_VOLTSETUP2_OFFSET);
+
+ temp = vdd-board_data-omap3_board_data.voltoffset;
+ temp = temp * omap_32k_clk_speed / (1000 * 1000) + 1;
+ vdd-write_reg(temp, prm_mod_offs, OMAP3_PRM_VOLTOFFSET_OFFSET);
According to the TRM (vZK, section 4.12.5.1.2), the VOLTOFFSET value
should be calculated based on the CLKSETUP and VOLTSETUP2 registers, so
we probably don't need a configurable value for this.
[...]
@@ -139,6 +163,61 @@ struct omap_vdd_info {
unsigned long target_volt);
};
+/**
+ * omap3_vdd_setuptime - vdd set up time info
+ * @voltsetup: setup time of the VDDregulators in us
+ * @clksetup : setup time of the oscillator system clock (sys_clk) in us
+ * @voltsetup2 : Overall setup time of VDDregulators in us
+ */
+struct omap3_vdd_setuptime {
+ u16 voltsetup;
+ u16 clksetup;
+ u16 voltsetup2;
+};
+
+/**
+ * omap3_volt_board_data - vdd set up time info for OMAP3
+ * @vdd_setup_ret: VDD setup time for retention mode
+ * @vdd_setup_off: VDD setup time for off mode
+ * @voltoffset : offset-time to de-assert sys_offmode
+ * when exiting the OFF mode
+ */
+struct omap3_volt_board_data {
+ struct omap3_vdd_setuptime vdd_setup_ret;
+ struct omap3_vdd_setuptime vdd_setup_off;
+ u16 voltoffset;
voltoffset can be dropped. Based on TRM, voltoffset can be calulated
(see comment above.)
+};
+
+/**
+ * omap4_volt_setuptime - vdd set up time info for OMAP4
+ * @voltsetup_ramp_up: VDD ram up time in us
+ * @voltsetup_ramp_down : VDD ram down time in us
+ */
+struct omap4_volt_setuptime {
+ u16
Re: [PATCH 0/5] regulator: twl: make 6030 regulators useable
On Fri, Apr 01, 2011 at 10:22:41AM +0530, Nishanth Menon wrote: TWL6030 regulator dynamic operations such as those on vaux2 and vaux3 were reported to be broken on platforms such as pandaboard(OMAP4). Digging deeper into the code, found that 6030 regulator support requires quiet a bit of fixes to make it useable. Major change w.r.t TWL4030 has been the introduction of CFG_STATE register in TWL6030 which is needed to be used for regulator control compared to messages which were used in TWL4030. Acked-by: Mark Brown broo...@opensource.wolfsonmicro.com -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/7] OMAP2+: powerdomain: add voltage domain lookup during register
On Wed, 23 Mar 2011, Cousson, Benoit wrote:
On 3/22/2011 11:08 PM, Paul Walmsley wrote:
On Tue, 22 Mar 2011, Cousson, Benoit wrote:
On the other hand not every clock belong to a clockdomain, that's why we
have clock without clockdomain on OMAP. A clockdomain is a just group of
IPs that share the same interface clock.
PRCM clockdomains also include functional clocks. See for example the
OMAP4 Public TRM Rev. O Section 3.1.1.1.3 Clock Domain ('The clockdomain
of CM_B is composed of two clocks: a functional clock (FCLK2) and an
interface clock (ICLK1)', and also later, 'The PRCM module lets software
check the status of the clock domain functional clocks').
True, but that does not change the definition of the clock domain (same
paragraph):
A clock domain is a group of modules fed by clock signals controlled by the
same clock manager in the PRCM module (see Figure 3-2).
My point was that a clock domain is related to modules that share some clocks.
So yes, a clock domain will contains modules and their related iclk and fclk.
But that does not means that every clocks will belong to a clockdomain.
All the non leaf clocks will not have any clock domain since they will not be
attached to any module directly.
In the OMAP Linux code, we use clockdomains for three purposes:
1. as a way to control the PRCM clockdomain hardware
2. as a way to associate clocks with powerdomains
3. as a way to group clocks that have similar idle behavior
So yes. All non-leaf clocks should be associated with OMAP Linux
clockdomains also, since those clocks will be associated with powerdomains
and also will be grouped by idle behavior.
Both the TRM and the OMAP4 functional specification clearly link PRCM
clockdomain idle management to the state of the clockdomain's functional
clocks. See for example OMAP4 Public TRM Rev. O Table 3-11 Clock Domain
Clock States ('INACTIVE: ... Every optional functional clock in the clock
domain is gated.')
That just means that each clock that supplies a module must be idled in order
to allow the clock domain to transition.
The clock domain FSM is using both iclk and fclk state to trigger the domain
transition, but that same clock could be used in another clock domain too.
When the same clock is used in another clockdomain, another struct clk is
created for that clock with a different clockdomain. We already have this
situation with OMAP3's 54MHz clock, for example.
Beyond the PRCM, the Linux-OMAP clockdomain code is not only concerned
with PRCM-controllable clockdomains. It is intended to be a generically
useful way to connect clocks to the powerdomain and voltagedomain that the
clock exists in, even if there are no explicit PRCM registers associated
with the clockdomain. These powerdomains and voltagedomains also may
not be directly PRCM controllable.
In that case, you cannot call that clockdomain anymore since this is not the
proper definition used by the PRCM. If you do not have a module, you cannot
have a clockdomain.
That may be the way that TI considers it in the AutoPRCM data or the
system PRCM, but the OMAP Linux clockdomain code uses a superset
definition and has done so for a few years now.
OMAP4 partitioning is following this hierarchy: module clockdomain
powerdomain voltagedomain device. The clocks are not part of the
hierarchy and for a good reason, the can be shared across the whole
device.
As mentioned before, each instance of a clock in a different clockdomain
should have a different struct clk associated with it.
Every clock that is in the Linux-OMAP clock tree should have a clockdomain
associated with it.
Mmm... What domain will you use for sys_clk
sys_clk and related clocks should go into a sys_clkdm or hf_sys_clkdm
or 32k_clk?
The external 32KiHZ oscillator should be associated with wkup_clkdm.
or for any DPLL or HS divider?
Those go into separate DPLL clockdomains. This is already there in OMAP3.
And what for?
2. as a way to associate clocks with powerdomains
3. as a way to group clocks that have similar idle behavior
Also, the original idea was to put autoidle control for the DPLLs and the
external HF clock LDO into the clockdomain layer, since it already had a
convenient concept for hardware automatic idle, vs. software controlled
idle. That part may not be needed any longer, now that we've added
autoidle support back into the clock code.
I know that the clockdomain name is confusing, but why do you want to change
its definition?
- 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: OMAP4 DSS clock setup
Hi Tomi, Benoît, et al,
On Wed, 30 Mar 2011, Tomi Valkeinen wrote:
Currently we have these aliases for OMAP4:
dss_clk - dss_dss_clk
fck - dss_fck
ick - dummy_ck
If that would be changed to:
fck - dss_dss_clk
ick - dss_fck
The driver would work the same way for all OMAPs.
This looks reasonable to me, and seems to match the TRM's Figure 10-4 DSS
Clock Tree.
The current OMAP4 clock data name dss_fck is just kind of a fake name
for that clock in the OMAP4 context.
Anyway. To get things working for rc2 (DSS currently crashes due to not
enabling dss_clk) we need to either:
1) Change the clock aliases as above
2) Add something like Sumit's patch (attached) to handle dss_clk. While
the patch is not that complex, it feels rather hacky.
Yeah, that patch looks like a hack to me, especially something like
this:
+ if (pdata-opt_clock_available(dss_clk)) {
Based on the E-mail thread so far, I'd say that changing the clock aliases
is the way to go for right now. The clock aliases are not hardware data;
they just control how the clock hardware is mapped to the drivers.
Of course, at some point soon, those clock aliases are going to go away.
But hopefully you all will have converted the driver over to PM runtime at
that point.
Once that happens, there's another problem: omap_hwmod_enable() is defined
that the hardware registers should be accessible by the MPU after it
completes. So by that definition, the hwmod code should be
enabling/disabling that dss_clk clock too when it enables/idles/shuts down
the hwmod. Probably we'd need to mark that struct omap_hwmod_opt_clk with
some flag. Then we'd need some kind of way for the DSS to tell the hwmod
code whether it is or isn't reliant on the PRCM-provided functional clock
for its internal functional clock. Maybe something like
omap_hwmod_{release,require}_system_fclk()?
- Paul
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Sat, 2 Apr 2011, Arnd Bergmann wrote: On Friday 01 April 2011 21:54:47 Nicolas Pitre wrote: I however don't think it is practical to go off in a separate mach-nocrap space and do things in parallel. Taking OMAP as an example, there is already way too big of an infrastructure in place to simply rewrite it in parallel to new OMAP versions coming up. It would be more useful and scalable to simply sit down, look at the current mess, and identify common patterns that can be easily factored out into some shared library code, and all that would be left in the board or SOC specific files eventually is the data to register with that library code. Nothing so complicated as grand plans or planification that makes it look like a mountain. This is exactly the question it comes down to. So far, we have focused on cleaning up platforms bit by bit. Given sufficient resources, I'm sure this can work. You assume that continuing on this path is the fastest way to clean up the whole mess, while my suggestion is based on the assumption that we can do better by starting a small fork. I don't think any fork would gain any traction. That would only, heh, fork the work force into two suboptimal branches for quite a while, and given that we're talking about platform code, by the time the new branch is usable and useful the hardware will probably be obsolete. The only way this may work is for totally new platforms but we're not talking about a fork in that case. I think we can both agree that by equally distributing the workforce to both approaches, we'd be off worse than doing one of them right ;-) Absolutely. I think what is needed here is a bunch of people willing to work on such things, extracting those common patterns, and creating the infrastructure to cover them. Once that is in place then we will be in a position to push back on code submissions that don't use that infrastructure, and be on the lookout for new patterns to emerge. Just with the above I think there is sufficient work to keep us busy for a while. That is true, and I think we will need to do this. But as far as I can tell, the problems that you talk about addressing are a different class from the ones I was thinking of, because they only deal with areas that are already isolated drivers with an existing API. They are areas with the best return on the investment. This has the potential of making quite a bunch of code go away quickly. And the goal is indeed to keep platform code hooking into existing APIs under control, so that global maintenance tasks such as the one tglx did are less painful. Obscure board code that no one else care about because no other boards share the same hardware model, and which doesn't rely on common kernel infrastructure, is not really a problem even if it looks like crap because no one will have to touch it. And eventually the board will become unused and we'll just delete that code. The things that I see as harder to do are where we need to change the way that parts of the platform code interact with each other: * platform specific IOMMU interfaces that need to be migrated to common interfaces This can be done by actually forking the platform specific IOMMU code only, just for the time required to migrate drivers to the common interface. * duplicated but slightly different header files in include/mach/ Oh, actually that's part of the easy problems. This simply require time to progressively do the boring work. With CONFIG_ARM_PATCH_PHYS_VIRT turned on we can get rid of almost all instances of arch/arm/mach-*/include/mach/memory.h already. Getting rid of all instances of arch/arm/mach-*/include/mach/vmalloc.h can be trivially achieved by simply moving the VMALLOC_END values into the corresponding struct machine_desc instances. And so on for many other files. This is all necessary for the single-binary multi-SOC kernel work anyway. * static platform device definitions that get migrated to device tree definitions. That require some kind of compatibility layer to make the transition transparent to users. I think Grant had some good ideas for this. Changing these tree-wide feels like open-heart surgery, and we'd spend much time trying not to break stuff that could better be used to fix other stuff. Well, depends how you see it. Sure this might cause some occasional breakages, but normally those should be pretty obvious and easy to fix. And the more we can do that stuff, the better future code adhering to the new model will be. The example that I have in mind is the time when we had a powerpc and a ppc architecture in parallel, with ppc supporting a lot of hardware that powerpc did not, but all new development getting done on powerpc. This took years longer than we had expected at first, but I still think it was a helpful fork. On ARM, we are in a much better shape in the core code than what
Re: Code for v2.6.39 merge window frozen, patches archived
On Thu, 31 Mar 2011, Aaro Koskinen wrote: Hi, On Wed, 30 Mar 2011, Kevin Hilman wrote: Tony Lindgren t...@atomide.com writes: FYI, looks like we've started hitting some booter -l kernel size limit in addition to booter -f size limit.. Now kernels built with omap2plus_defconfig won't boot on n900 any longer. I guess you are seeing it just hanging at Uncompressing Linux... done, booting the kernel.? I guess the way around that is to install the u-boot loader package. Alternatively CONFIG_KERNEL_LZMA=y will get the kernel zImage size back within size limits that will boot on n900. Hmm, I'm a bit puzzled. For me, .38 works but .39-rc1 does not, and I can't see any special limit exceeded. Also LZMA is broken: Uncompressing Linux... LZMA data is corrupt -- System halted I did some bisecting, and with the following commit reverted -rc1 works: commit d239b1dc093d551046a909920b5310c1d1e308c1 Author: Nicolas Pitre nicolas.pi...@linaro.org Date: Mon Feb 21 04:57:38 2011 +0100 ARM: 6746/1: remove the 4x expansion presumption while decompressing the kernel With the revert, also bigger gzipped kernel works. OK I will have a look. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Fri, Apr 01, 2011 at 03:54:47PM -0400, Nicolas Pitre wrote: 1) GPIO drivers As Linus observed, in the majority of the cases GPIOs are accessed through simple memory-mapped registers. Some have absolute state registers, the others have separate clear/set registers. Suffice to create two generic GPIO drivers each covering those two common cases, and those generic drivers would simply register with the higher level gpiolib code, and all the board code would have to do is to provide the data for those GPIOs (register offsets, number of GPIOs, etc.). Whether this data eventually comes from DT is an orthogonal issue. For this case we actually already have the basic_mmio_gpio driver in tree, we should be pushing for wider usage of that. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Fri, Apr 01, 2011 at 05:55:57PM +0200, Arnd Bergmann wrote: On Friday 01 April 2011, Will Deacon wrote: I don't understand how you can handle `early quirks' without board files. Does this follow on from Linus' suggestion about moving code out of the kernel and into the bootloader? There are multiple ways of dealing with this. One way would be to mandate that the boot loader does the quirks, ideally as little as possible. Though we then get into the issues with bootloader quality and risk Another option is to have a boot wrapper with board specific code, which gets run between the regular boot loader and the common kernel entry point. We might need such a wrapper anyway to pass the device tree to the kernel. This sounds an awful lot like a board file which doesn't get to use any of the in-kernel infrastructure like bus controller drivers or chip drivers to help which feels retrograde. I understand where you're coming from on this but an absolute ban feels overly restrictive here, it seems like we'd be better off allowing board files but pushing back strongly on anything that should be data... Realistically, I don't think you will ever get away from board files. The trick is probably to make them as small as possible and common to as many boards as possible (like the platforms directory for PowerPC). Perhaps. But we can start out with strict rules and add exceptions later when we run out of options. ...which is pretty much what you're saying here. -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap changes for v2.6.39 merge window
On Fri, Apr 01, 2011 at 04:19:31PM -0400, Nicolas Pitre wrote: In a perfect world the bootloader would be bug free and always up to date with the best DT data. In practice I'm very skeptical this will always be the case and painless. At least the above makes it very simple to have a self contained kernel when (not if) need be. Yes, my experience with DT on powerpc teaches me that, although DT sounds wonderful in theory, in practice kernel/dtb/uboot form a love triangle (or perhaps a hate triangle) where all three points must be exactly up to date with each other. If one part is even just a month or two too old/new, then your kernel might not boot. Richard -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: arm: pmu: support pmu/perf on OMAP4 - booting problem on pandaboard
Hi Avik, 2011/4/1 Avik Sil avik...@linux.vnet.ibm.com: Hi, I've applied the patches in http://lists.infradead.org/pipermail/linux-arm-kernel/2011-March/045283.html on top of a linaro kernel which resulted in booting problem on Pandaboard. It hangs inside the cti_unlock() while reading the LOCKSTATUS value, which happens when omap_init_pmu() is called. Please help me debug the issue. Please check if l3 clocks are enabled to drive CTI, such as done in below: omap_writel(1, CM_L3INSTR_L3_3_CLKCTRL); omap_writel(1, CM_L3INSTR_L3_INSTR_CLKCTRL); omap_writel(2, CM_EMU_CLKSTCTRL); while ((omap_readl(CM_EMU_CLKSTCTRL) 0x300) != 0x300); No such issue on mainline since this clocks are enabled automatically. thanks, -- Ming Lei -- 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
