Re: [PATCH v2 1/2] clk: change clk_ops' ->round_rate() prototype
Hi Boris, On 05/06/15 12:39, Boris Brezillon wrote: > Hi Jon, > > On Fri, 5 Jun 2015 09:46:09 +0100 > Jon Hunter wrote: > >> >> On 05/06/15 00:02, Paul Walmsley wrote: >>> Hi folks >>> >>> just a brief comment on this one: >>> >>> On Thu, 30 Apr 2015, Boris Brezillon wrote: >>> Clock rates are stored in an unsigned long field, but ->round_rate() (which returns a rounded rate from a requested one) returns a long value (errors are reported using negative error codes), which can lead to long overflow if the clock rate exceed 2Ghz. Change ->round_rate() prototype to return 0 or an error code, and pass the requested rate as a pointer so that it can be adjusted depending on hardware capabilities. >>> >>> ... >>> diff --git a/Documentation/clk.txt b/Documentation/clk.txt index 0e4f90a..fca8b7a 100644 --- a/Documentation/clk.txt +++ b/Documentation/clk.txt @@ -68,8 +68,8 @@ the operations defined in clk.h: int (*is_enabled)(struct clk_hw *hw); unsigned long (*recalc_rate)(struct clk_hw *hw, unsigned long parent_rate); - long(*round_rate)(struct clk_hw *hw, - unsigned long rate, + int (*round_rate)(struct clk_hw *hw, + unsigned long *rate, unsigned long *parent_rate); long(*determine_rate)(struct clk_hw *hw, unsigned long rate, >>> >>> I'd suggest that we should probably go straight to 64-bit rates. There >>> are already plenty of clock sources that can generate rates higher than >>> 4GiHz. >> >> An alternative would be to introduce to a frequency "base" the default >> could be Hz (for backwards compatibility), but for CPUs we probably only >> care about MHz (or may be kHz) and so 32-bits would still suffice. Even >> if CPUs cared about Hz they could still use Hz, but in that case they >> probably don't care about GHz. Obviously, we don't want to break DT >> compatibility but may be the frequency base could be defined in DT and >> if it is missing then Hz is assumed. Just a thought ... > > Yes, but is it really worth the additional complexity. You'll have to > add the unit information anyway, so using an unsigned long for the > value and another field for the unit (an enum ?) is just like using a > 64 bit integer. For a storage perspective, yes it would be the same. However, there are probably a lot of devices that would not need the extra range, but would now have to deal with 64-bit types. I have no idea how much overhead that would be in reality. If the overhead is negligible then a 64-bit type is definitely the way to go, as I agree it is simpler and cleaner. Cheers Jon -- 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: EDMA oftree entry for AM335x
On Wed, May 06, 2015 at 07:39:52AM -0700, Tony Lindgren wrote:
> > In different SoC we can have different number of CCs (OMAP-L138 has two) and
> > each CC can have different number of TCs associated with. In AM335x we have
> > one CC with 3 TC, in OMAP-L138 we have two CC, CC0 has 2 TC, CC1 has 1 TC.
> > The
> > TCs are used to set priorities, you can assign the priorities to the TCs and
> > you can choose to assign the transfer (channel) to a give TC.
>
> OK
>
> > >> And yes, both TC and CCs can generate interrupts.
> > >
> > > Do the TCs have a shared interrupt that could be handled by
> > > each TC instance?
> >
> > Separate IRQ lines to the ARM core, but we do not handle them right now.
>
> OK
>
> > >> So it is not straight forward to separate the TC from the CC driver
> > >> (edma3).
> > >
> > > It seems pm runtime for these four separate modules needs to be
> > > done at the CC driver level if it can't be done separately for
> > > each instance.
> >
> > The current eDMA stack is not really flexible on this IMHO.
> > I think the way forward would be something like this in DT:
> >
> > edma_cc: edma_cc@4900 {
> > compatible = "ti,edma3-cc";
> > ti,hwmods = "tpcc"
> > reg = <0x4900 0x1>,
> > <0x44e10f90 0x40>;
> > interrupts = <12 13 14>;
> > #dma-cells = <1>;
> >
> > edma3_tc0: edma3_tc0@4980 {
> > compatible = "ti,edma3-tc";
> > ti,hwmods = "tptc0"
> > };
> >
> > edma3_tc1: edma3_tc1@4990 {
> > compatible = "ti,edma3-tc";
> > ti,hwmods = "tptc1"
> > };
> >
> > edma3_tc2: edma3_tc2@49a0 {
> > compatible = "ti,edma3-tc";
> > ti,hwmods = "tptc2"
> > };
> > };
>
> Yeah that would be an improvment and remove the blockers for further
> hwmod work. It would still be better to have the TC probe separately
> and register with CC rather than combining separate elements in DT
> in a way that does not represent the hardare. There's a 7MB reserved
> block inbetween there..
>
> > The driver for ti,edma3-tc would be pretty minimal, doing only pm_runtime
> > only
> > and from the CC driver we could just set the runtime status for the the TC
> > which we are about to submit work and decrement the runtime when the work is
> > done. If not work is needed for the TC it can be shot down.
>
> OK
>
> > But this would need significant amount of work which can be done when we get
> > rid of the legacy (arch/arm/common/edma.c) and move to dmaengine only mode.
>
> That may never happen considering that davinci is using it too.. It's
> best to not count on that happening anytime soon at least.
So my current understanding is that we have the situation that the
kernel warns about the oftree being wrong, but isn't able to handle an
oftree that would be right.
Shouldn't the warning being added when the kernel driver supports that
new mechanism?
I had a warning free mainline kernel without patches on my customer
hardware before, so this smells a bit like a regression ... :-/
rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 0/2] dmaengine: ti-dma-crossbar: Support for eDMA
Hi, Changes since v01: - Drop change in compatible for the crossbar driver and do the configuration based on the DT structure. The ti-dma-crossbar driver in it's current form can work when it is used with sDMA (omap-dma). On DRA7x class of devices we have both sDMA and eDMA available. The sDMA driver expects to get the DMA request line with offset 1. The eDMA stack does not need the offset. The crosbbar itself is identical for sDMA and eDMA. At probe time the driver will do a match to figure out which dma engine it is connected to and based on that information it will configure the offset needed by the DMA driver. Regards, Peter --- Misael Lopez Cruz (1): dmaengine: ti-dma-crossbar: Make idr xbar instance-specific Peter Ujfalusi (1): dmaengine: ti-dma-crossbar: Add support for eDMA drivers/dma/ti-dma-crossbar.c | 34 +- 1 file changed, 29 insertions(+), 5 deletions(-) -- 2.4.2 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 2/2] dmaengine: ti-dma-crossbar: Add support for eDMA
The crossbar for eDMA works exactly the same way as sDMA, but sDMA
requires an offset of 1, while no offset is needed for eDMA.
Based on the patch from Misael Lopez Cruz
Signed-off-by: Peter Ujfalusi
CC: Misael Lopez Cruz
---
drivers/dma/ti-dma-crossbar.c | 27 +--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/ti-dma-crossbar.c b/drivers/dma/ti-dma-crossbar.c
index 1fd3fb73d6e8..10487d91e60d 100644
--- a/drivers/dma/ti-dma-crossbar.c
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -20,6 +20,9 @@
#define TI_XBAR_OUTPUTS127
#define TI_XBAR_INPUTS 256
+#define TI_XBAR_EDMA_OFFSET0
+#define TI_XBAR_SDMA_OFFSET1
+
struct ti_dma_xbar_data {
void __iomem *iomem;
@@ -29,6 +32,7 @@ struct ti_dma_xbar_data {
u16 safe_val; /* Value to rest the crossbar lines */
u32 xbar_requests; /* number of DMA requests connected to XBAR */
u32 dma_requests; /* number of DMA requests forwarded to DMA */
+ u32 dma_offset;
};
struct ti_dma_xbar_map {
@@ -84,8 +88,7 @@ static void *ti_dma_xbar_route_allocate(struct
of_phandle_args *dma_spec,
GFP_KERNEL);
map->xbar_in = (u16)dma_spec->args[0];
- /* The DMA request is 1 based in sDMA */
- dma_spec->args[0] = map->xbar_out + 1;
+ dma_spec->args[0] = map->xbar_out + xbar->dma_offset;
dev_dbg(&pdev->dev, "Mapping XBAR%u to DMA%d\n",
map->xbar_in, map->xbar_out);
@@ -95,9 +98,22 @@ static void *ti_dma_xbar_route_allocate(struct
of_phandle_args *dma_spec,
return map;
}
+static const struct of_device_id ti_dma_master_match[] = {
+ {
+ .compatible = "ti,omap4430-sdma",
+ .data = (void *)TI_XBAR_SDMA_OFFSET,
+ },
+ {
+ .compatible = "ti,edma3",
+ .data = (void *)TI_XBAR_EDMA_OFFSET,
+ },
+ {},
+};
+
static int ti_dma_xbar_probe(struct platform_device *pdev)
{
struct device_node *node = pdev->dev.of_node;
+ const struct of_device_id *match;
struct device_node *dma_node;
struct ti_dma_xbar_data *xbar;
struct resource *res;
@@ -120,6 +136,12 @@ static int ti_dma_xbar_probe(struct platform_device *pdev)
return -ENODEV;
}
+ match = of_match_node(ti_dma_master_match, dma_node);
+ if (!match) {
+ dev_err(&pdev->dev, "DMA master is not supported\n");
+ return -EINVAL;
+ }
+
if (of_property_read_u32(dma_node, "dma-requests",
&xbar->dma_requests)) {
dev_info(&pdev->dev,
@@ -151,6 +173,7 @@ static int ti_dma_xbar_probe(struct platform_device *pdev)
xbar->dmarouter.dev = &pdev->dev;
xbar->dmarouter.route_free = ti_dma_xbar_free;
+ xbar->dma_offset = (u32)match->data;
platform_set_drvdata(pdev, xbar);
--
2.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/2] dmaengine: ti-dma-crossbar: Make idr xbar instance-specific
From: Misael Lopez Cruz
In preparation for supporting multiple DMA crossbar instances,
make the idr xbar instance specific.
Signed-off-by: Misael Lopez Cruz
Signed-off-by: Peter Ujfalusi
---
drivers/dma/ti-dma-crossbar.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/ti-dma-crossbar.c b/drivers/dma/ti-dma-crossbar.c
index 24f5ca2356bf..1fd3fb73d6e8 100644
--- a/drivers/dma/ti-dma-crossbar.c
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -20,12 +20,11 @@
#define TI_XBAR_OUTPUTS127
#define TI_XBAR_INPUTS 256
-static DEFINE_IDR(map_idr);
-
struct ti_dma_xbar_data {
void __iomem *iomem;
struct dma_router dmarouter;
+ struct idr map_idr;
u16 safe_val; /* Value to rest the crossbar lines */
u32 xbar_requests; /* number of DMA requests connected to XBAR */
@@ -51,7 +50,7 @@ static void ti_dma_xbar_free(struct device *dev, void
*route_data)
map->xbar_in, map->xbar_out);
ti_dma_xbar_write(xbar->iomem, map->xbar_out, xbar->safe_val);
- idr_remove(&map_idr, map->xbar_out);
+ idr_remove(&xbar->map_idr, map->xbar_out);
kfree(map);
}
@@ -81,7 +80,7 @@ static void *ti_dma_xbar_route_allocate(struct
of_phandle_args *dma_spec,
return ERR_PTR(-ENOMEM);
}
- map->xbar_out = idr_alloc(&map_idr, NULL, 0, xbar->dma_requests,
+ map->xbar_out = idr_alloc(&xbar->map_idr, NULL, 0, xbar->dma_requests,
GFP_KERNEL);
map->xbar_in = (u16)dma_spec->args[0];
@@ -113,6 +112,8 @@ static int ti_dma_xbar_probe(struct platform_device *pdev)
if (!xbar)
return -ENOMEM;
+ idr_init(&xbar->map_idr);
+
dma_node = of_parse_phandle(node, "dma-masters", 0);
if (!dma_node) {
dev_err(&pdev->dev, "Can't get DMA master node\n");
--
2.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] omap fixes for v4.1, urgent fix to avoid potential hardware damage
Tony Lindgren writes: > Hi, > > Here's a pull request to fix potential hardware breaking configuration > on BeagleBones. For the other fixes, apologies for these coming in so > late, seems that people have been busy finding regressions. > > Regards, > > Tony > > > The following changes since commit f25bf74c8862efdc30453d16d60cf22958a4873e: > > ARM: dts: Fix WLAN interrupt line for AM335x EVM-SK (2015-05-20 10:00:10 > -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap > tags/omap-for-v4.1/fixes-rc6 > > for you to fetch changes up to 7a6cb0abe1aa63334f3ded6d2b6c8eca80e72302: > > ARM: dts: am335x-boneblack: disable RTC-only sleep to avoid hardware damage > (2015-06-01 12:48:23 -0700) > > > Omap fixes for the -rc cycle, including a fix for potential hardware > breakage on BeagleBones: > > - BeagleBones don't support RTC-only mode, it can cause hardware > damage if system-power-controller is specified without > ti,pmic-shutdown-controller > > - Fix a recent regression to am3517 SoCs caused by the recent clock > move that was not noticed until now despite automated boot > testing > > - Fix a regression for n900 touchscreen triggered by recent > recent input changes > > - Fix compatible property for dm816x USB to avoid errors with > USB Ethernet > > - Fix oops for omap3 when built with CONFIG_THUMB2_KERNEL > Thanks, applied to fixes. 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: next-20150604 build: 2 failures 37 warnings (next-20150604)
On Fri, Jun 05, 2015 at 06:16:52PM +0100, Mark Brown wrote: > On Fri, Jun 05, 2015 at 07:49:00PM +0900, Greg Kroah-Hartman wrote: > > On Thu, Jun 04, 2015 at 10:20:26AM -0700, Tony Lindgren wrote: > > > > Greg, there's now commit 9809889c708e in tty-linus and commit > > > 9e91597f2423 in tty-next. > > > Yes, I can't go back and remove the one in tty-next, I'm guessing when > > they are merged there is an issue. I'll look into that after Linus > > pulls in my tty-linus tree. > > Yeah, git isn't always spectacularly good at resolving add/add if > there's context changes between two things in a merge - it sometimes > ends up double adding things. Ok, I've now merged these branches together, if someone can verify that my tty-next branch is correct, that would be great. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: AM35xx: fix system control module clocks
Hello Paul, On 07-06-15 21:56, Paul Walmsley wrote: On Sun, 7 Jun 2015, Jeroen Hofstee wrote: Turns out my suspicion was wrong. This is what I know at the moment, depending on the bootpins, u-boot will trigger a bad access when loading a file over ethernet, but only the first time. Clearing the pending interrupt before booting linux make the "USB_OTG address hole seen" go away. Oh, too bad. I had been hoping that you were right and that I was wrong ;-) I'll try this on the CM-T3517 here. I'd like to solicit your opinion on what to do here. I wonder if, in the L3 bus drivers, we should simply report, in a line or two, if any bus errors were logged before the kernel starts? That would help discriminate between problems that the kernel is responsible for, vs. problems that occur earlier in the boot process. Any thoughts? I am not sure this can be easily done in a general manner. Since in general linux doesn't know the bootloader, it can't rely on what peripherals are setup, so I doubt it is in general possible to store a copy of the interrupt registers really early. Besides that, when not hacking around, I guess during the really early boot stage it is unknown what the interrupt registers are in the first place and which clocks are needed. And even if it could be done, if there is a bug in that code, it would lead to bigger problems than it is trying to solve (a bit weird backlogs). I guess it would be easier to check these flags in u-boot right before the jump to linux (there is a cleanup_before_linux() or something name like that). [ Or fake the boot and run the check as a separate command]. Unfortunately u-boot does not have a complete driver model, so a implementation of that in todays u-boot will lead to a complete #ifdef CONFIG_foo mesh. So, if you ask me, no don't add it to linux, but to u-boot instead. But likely as feature for a later release which can query all drivers. (and doubt this should be limited to interrupt flags, runtime_test() could be called on all of them e.g. when entering a command like runtime_test). Regards, Jeroen -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: dts: AM35xx: fix system control module clocks
Hello Paul, +Menon (since you asked about the USB_OTG trap), On 08-06-15 04:38, Paul Walmsley wrote: Hi Jeroen, On Sun, 7 Jun 2015, Paul Walmsley wrote: On Sun, 7 Jun 2015, Jeroen Hofstee wrote: Turns out my suspicion was wrong. This is what I know at the moment, depending on the bootpins, u-boot will trigger a bad access when loading a file over ethernet, but only the first time. Clearing the pending interrupt before booting linux make the "USB_OTG address hole seen" go away. Oh, too bad. I had been hoping that you were right and that I was wrong ;-) I'll try this on the CM-T3517 here. I used your debugging technique here and was able to reproduce your results - with one difference: http://www.pwsan.com/omap/testlogs/test_v4.1-rc6/20150607194102/boot/cmt3517/cmt3517_log.txt The interconnect error was logged upon the first interaction with the network. In my case this was with the U-boot 'dhcp' command. The pending interrupt bit was cleared before loading the kernel via tftp, and the interrupt bit was not set again, even after a tftp load. I sent a patch to u-boot to disable the offending line, see [1]. It would be interesting to know if it can also result in valid, accidental memory adjustments, before the invalid one, but I haven't checked that yet. Regards, Jeroen [1] https://patchwork.ozlabs.org/patch/481751/ p.s. the USB_OTG trap is actually a musb / emac / camera trap on an am3517. -- 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] fbdev: omap2: remove potential format string leak
Since kobject_init_and_add takes a format string, make sure that the
passed in name cannot be accidentally parsed.
Signed-off-by: Kees Cook
---
drivers/video/fbdev/omap2/dss/display-sysfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/dss/display-sysfs.c
b/drivers/video/fbdev/omap2/dss/display-sysfs.c
index 12186557a9d4..6ad0991f8259 100644
--- a/drivers/video/fbdev/omap2/dss/display-sysfs.c
+++ b/drivers/video/fbdev/omap2/dss/display-sysfs.c
@@ -324,7 +324,7 @@ int display_init_sysfs(struct platform_device *pdev)
for_each_dss_dev(dssdev) {
r = kobject_init_and_add(&dssdev->kobj, &display_ktype,
- &pdev->dev.kobj, dssdev->alias);
+ &pdev->dev.kobj, "%s", dssdev->alias);
if (r) {
DSSERR("failed to create sysfs files\n");
omap_dss_put_device(dssdev);
--
1.9.1
--
Kees Cook
Chrome OS Security
--
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
