* [PATCH] clk: sunxi: fix overflow when setting up divided factors
From: Mike Turquette @ 2014-01-27 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390613561-28636-1-git-send-email-emilio@elopez.com.ar>
Quoting Emilio L?pez (2014-01-24 17:32:41)
> Currently, we are allocating space for two pointers, when we actually
> may need to store three of them (two divisors plus the original clock).
> Fix this, and change sizeof(type) to sizeof(*var) to keep checkpatch.pl
> happy.
>
> Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
> Signed-off-by: Emilio L?pez <emilio@elopez.com.ar>
> ---
>
> Hi Mike,
>
> Is there any chance you can include this oneliner on your second part of
> the pull request to Linus?
Done.
Regards,
Mike
>
> Cheers,
>
> Emilio
>
> drivers/clk/sunxi/clk-sunxi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> index 659e4ea..abb6c5a 100644
> --- a/drivers/clk/sunxi/clk-sunxi.c
> +++ b/drivers/clk/sunxi/clk-sunxi.c
> @@ -875,7 +875,7 @@ static void __init sunxi_divs_clk_setup(struct device_node *node,
> if (!clk_data)
> return;
>
> - clks = kzalloc(SUNXI_DIVS_MAX_QTY * sizeof(struct clk *), GFP_KERNEL);
> + clks = kzalloc((SUNXI_DIVS_MAX_QTY+1) * sizeof(*clks), GFP_KERNEL);
> if (!clks)
> goto free_clkdata;
>
> --
> 1.8.5.3
>
^ permalink raw reply
* [PATCH] ARM: OMAP4+: move errata initialization to omap4_pm_init_early
From: Kevin Hilman @ 2014-01-27 20:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140123184951.GJ7993@atomide.com>
Tony Lindgren <tony@atomide.com> writes:
> * Kevin Hilman <khilman@linaro.org> [140123 09:55]:
>> Grygorii Strashko <grygorii.strashko@ti.com> writes:
>>
>> > On 01/20/2014 10:06 PM, Nishanth Menon wrote:
>> >> Move all OMAP4 PM errata initializations to centralized location in
>> >> omap4_pm_init_early. This allows for users to utilize the erratas
>> >> in various submodules as needed.
>> >>
>> > Tested-by: Grygorii Strashko <grygorii.strashko@ti.com>
>> >
>> > This patch fixes build failure caused by patch
>> > https://patchwork.kernel.org/patch/3084521/
>> > in case if SMP is not enabled.
>>
>> So does that mean that that patch can now be applied as is?
>>
>> We could sure use that fix (or equivalent) for CPUidle breakage on 4460.
>
> Yeah, seems OK to me, feel free to apply it directly:
>
> Acked-by: Tony Lindgren <tony@atomide.com>
OK, I've picked up both $SUBJECT patch and the one from the above
patchworks link and will queue them up for v3.14-rc (and have added your
Ack to both.)
Thanks,
Kevin
^ permalink raw reply
* [PATCH] arm64: Add pdev_archdata for dmamask
From: Russell King - ARM Linux @ 2014-01-27 20:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390854331.23180.22.camel@localhost.localdomain>
On Mon, Jan 27, 2014 at 09:25:31PM +0100, Yann Droneaud wrote:
> ARM, even AAAAARGH64 [1], doesn't need a special treatement regarding
> the infamous dma_mask pointer. So perhaps my solution is better.
>
> This solution (adding dma_mask in pdev_archdata) is already in use in
> powerpc architecture. See arch/powerpc/kernel/setup-common.c
>
> The advantage of this solution is that it makes a dma_mask placeholder
> available to statically allocated platform_device struct, while mine
> only address the problem for platform_device struct allocated with
> platform_device_alloc().
As I've already said in this thread, the basic problem comes from DT's
platform device creation. It's the responsibility of the device creator
to set the dma_mask pointer appropriately, and DT doesn't do that. So,
DT needs to be fixed rather than everyone introducing their own
workarounds for this.
> I'm also considering using dma_set_mask_and_coherent() in
> platform_device_register_full() and drivers using
> platform_device_alloc().
As the one who introduced dma_set_mask_and_coherent, consider this a
strong NAK on that. The reason is dma_set_mask_and_coherent() is
for drivers to set their requirements, not for the bus requirements
to be set in the first place.
It also means that drivers which need no DMA support are subjected to
DMA restrictions (in that dma_set_mask_and_coherent can error out if
the platform can't support the DMA mask.)
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH 2/4] ASoC: tda998x: add a codec driver for TDA998x
From: Mark Brown @ 2014-01-27 20:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <a62784e8778d06512d49a24dcf59ff9e45839902.1390813481.git.moinejf@free.fr>
On Sun, Jan 26, 2014 at 07:45:36PM +0100, Jean-Francois Moine wrote:
> select SND_SOC_STAC9766 if SND_SOC_AC97_BUS
> select SND_SOC_TAS5086 if I2C
> + select SND_SOC_TDA998X if I2C
> +config SND_SOC_TDA998X
> + tristate
> + depends on OF
> + default y if DRM_I2C_NXP_TDA998X=y
> + default m if DRM_I2C_NXP_TDA998X=m
> +
These two things don't seem to agree with each other, and I expect this
breaks the build for ALL_CODECS.
> +static void tda_get_encoder(struct tda_priv *priv)
> +{
> + struct snd_soc_codec *codec = priv->codec;
> + struct device_node *np;
> + struct i2c_client *i2c_client;
> + static const struct of_device_id tda_dt[] = {
> + { .compatible = "nxp,tda998x" },
> + { },
> + };
> +
> + /* search the tda998x device */
> + np = of_find_matching_node_and_match(NULL, tda_dt, NULL);
> + if (!np || !of_device_is_available(np)) {
> + dev_err(codec->dev, "No tda998x in DT\n");
> + return;
> + }
> + i2c_client = of_find_i2c_device_by_node(np);
> + of_node_put(np);
> + if (!i2c_client) {
> + dev_err(codec->dev, "no tda998x i2c client\n");
> + return;
> + }
> + if (!i2c_get_clientdata(i2c_client)) {
> + dev_err(codec->dev, "tda998x not initialized\n");
> + return;
> + }
> +
> + priv->i2c_client = i2c_client;
> +}
The normal way of doing this would be to make the device a MFD - that
way the frameworks make sure probe ordering and so on are sorted out.
Other than that this looks basically OK, a few small comments below.
> + /* give the audio input type and ports to the HDMI encoder */
> + format = start ? priv->dai_id : 0;
It's not clear to me what the above is doing (I think I know but it
requires thinking about rather than being clear).
> +static const struct snd_soc_dai_driver tda998x_dai[] = {
> + {
> + .name = "i2s-hifi",
Coding style, indents are tabs.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140127/f42da9a3/attachment-0001.sig>
^ permalink raw reply
* [PATCH 3/4] ASoC: tda998x: add DT documentation
From: Mark Brown @ 2014-01-27 20:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <22fafd7e11771ffc25c84ff609d18039f07b7295.1390813481.git.moinejf@free.fr>
On Mon, Jan 27, 2014 at 09:34:49AM +0100, Jean-Francois Moine wrote:
> + - compatible: must be "nxp,tda998x-codec".
> + - audio-ports: one or two values.
> + The first value defines the I2S input port.
> + The second one, if present, defines the S/PDIF input port.
I take it these are port numbers on the device and it's not possible to
do something like having multiple I2S ports?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140127/d73158a4/attachment.sig>
^ permalink raw reply
* [PATCH 0/2] clk: shmobile rcar-gen2 fixes
From: Mike Turquette @ 2014-01-27 20:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <2118020.lZAv6IL4Xy@avalon>
Quoting Laurent Pinchart (2014-01-21 05:00:28)
> Hi Mike,
>
> On Wednesday 08 January 2014 00:06:39 Laurent Pinchart wrote:
> > On Tuesday 07 January 2014 17:59:01 Geert Uytterhoeven wrote:
> > > On Tue, Jan 7, 2014 at 5:47 PM, Laurent Pinchart wrote:
> > > > Geert, could you please verify that the series fixes your QSPI clock
> > > > issues with the Koelsch board ?
> > > >
> > > > Laurent Pinchart (2):
> > > > clk: shmobile: rcar-gen2: Fix clock parent all non-PLL clocks
> > > > clk: shmobile: rcar-gen2: Fix qspi divisor
> > >
> > > Thanks, both:
> > >
> > > Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
> >
> > Thank you.
> >
> > Mike, could you please pick those patches up for v3.14 ?
>
> Ping ?
Hi Laurent,
I'll send these as part of my fixes tag, probably next week.
Regards,
Mike
>
> --
> Regards,
>
> Laurent Pinchart
>
^ permalink raw reply
* [PATCH 4/4] ASoC: tda998x: adjust the audio hw parameters from EDID
From: Mark Brown @ 2014-01-27 20:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d99e90932aad1a644fa32ff22fd2cb56b830341b.1390813481.git.moinejf@free.fr>
On Mon, Jan 27, 2014 at 09:48:54AM +0100, Jean-Francois Moine wrote:
> + eld_ver = eld[0] >> 3;
> + if (eld_ver != 2 && eld_ver != 31)
> + return 0;
> +
> + mnl = eld[4] & 0x1f;
> + if (mnl > 16)
> + return 0;
> +
> + sad_count = eld[5] >> 4;
> + sad = eld + 20 + mnl;
Can this parsing code be factored out - it (or large parts of it) should
be usable by other HDMI devices shouldn't it?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140127/2ec34ffc/attachment.sig>
^ permalink raw reply
* [PATCH 3/4] ASoC: tda998x: add DT documentation
From: Russell King - ARM Linux @ 2014-01-27 20:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127204302.GY11841@sirena.org.uk>
On Mon, Jan 27, 2014 at 08:43:02PM +0000, Mark Brown wrote:
> On Mon, Jan 27, 2014 at 09:34:49AM +0100, Jean-Francois Moine wrote:
>
> > + - compatible: must be "nxp,tda998x-codec".
> > + - audio-ports: one or two values.
> > + The first value defines the I2S input port.
> > + The second one, if present, defines the S/PDIF input port.
>
> I take it these are port numbers on the device and it's not possible to
> do something like having multiple I2S ports?
You can feed it with multiple synchronised I2S streams for the additional
channels.
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH RFC v3 3/8] ASoC: davinci-mcasp: Set BCLK divider if McASP is BCLK master
From: Mark Brown @ 2014-01-27 20:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <27d041ee149081cd9b401939d4382e73fba5e7a5.1390836773.git.jsarha@ti.com>
On Mon, Jan 27, 2014 at 05:37:52PM +0200, Jyri Sarha wrote:
> Make BCLK divider setting implicite in hw_params call if McASP device
> is the bit clock master on the audio serial bus.
Applied, thanks.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140127/264185d7/attachment.sig>
^ permalink raw reply
* [PATCH RFC v3 4/8] ASoC: davinci-evm: HDMI audio support for TDA998x trough McASP I2S bus
From: Mark Brown @ 2014-01-27 20:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <86fcca2ecf302a695e7fd8199a1d635a67bbfcc8.1390836773.git.jsarha@ti.com>
On Mon, Jan 27, 2014 at 05:37:53PM +0200, Jyri Sarha wrote:
> Add machine driver support for BeagleBone-Black and other boards with
> tilcdc support and NXP TDA998X HDMI transmitter connected to McASP
> port in I2S mode. McASP produces the bit clock for the i2s bus from
> the masted clock by a simple divider and the available sample rates
I have to say I agree with Lars' comments about where the code to set
the constraints is here - I don't doubt that these limitations are valid
but it would be better to factor them into the relevant chip drivers so
that other systems with similar limitations can be handled correctly
too.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140127/9e5ad4e2/attachment.sig>
^ permalink raw reply
* [PATCH 4/4] ASoC: tda998x: adjust the audio hw parameters from EDID
From: Russell King - ARM Linux @ 2014-01-27 20:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127204441.GZ11841@sirena.org.uk>
On Mon, Jan 27, 2014 at 08:44:41PM +0000, Mark Brown wrote:
> On Mon, Jan 27, 2014 at 09:48:54AM +0100, Jean-Francois Moine wrote:
>
> > + eld_ver = eld[0] >> 3;
> > + if (eld_ver != 2 && eld_ver != 31)
> > + return 0;
> > +
> > + mnl = eld[4] & 0x1f;
> > + if (mnl > 16)
> > + return 0;
> > +
> > + sad_count = eld[5] >> 4;
> > + sad = eld + 20 + mnl;
>
> Can this parsing code be factored out - it (or large parts of it) should
> be usable by other HDMI devices shouldn't it?
Yes, preferably as a generic ALSA helper rather than an ASoC helper -
I don't see any need for this to be ASoC specific (I have a pure ALSA
driver which has very similar code in it.)
--
FTTC broadband for 0.8mile line: 5.8Mbps down 500kbps up. Estimation
in database were 13.1 to 19Mbit for a good line, about 7.5+ for a bad.
Estimate before purchase was "up to 13.2Mbit".
^ permalink raw reply
* [PATCH 4/4] ASoC: tda998x: adjust the audio hw parameters from EDID
From: Mark Brown @ 2014-01-27 20:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127204915.GC15937@n2100.arm.linux.org.uk>
On Mon, Jan 27, 2014 at 08:49:15PM +0000, Russell King - ARM Linux wrote:
> On Mon, Jan 27, 2014 at 08:44:41PM +0000, Mark Brown wrote:
> > Can this parsing code be factored out - it (or large parts of it) should
> > be usable by other HDMI devices shouldn't it?
> Yes, preferably as a generic ALSA helper rather than an ASoC helper -
> I don't see any need for this to be ASoC specific (I have a pure ALSA
> driver which has very similar code in it.)
Indeed, definitely ALSA generic - ideally we could factor a lot of the
integration with the video side out.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140127/2d20285d/attachment.sig>
^ permalink raw reply
* [PATCH 3/4] ASoC: tda998x: add DT documentation
From: Mark Brown @ 2014-01-27 20:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127204534.GB15937@n2100.arm.linux.org.uk>
On Mon, Jan 27, 2014 at 08:45:34PM +0000, Russell King - ARM Linux wrote:
> On Mon, Jan 27, 2014 at 08:43:02PM +0000, Mark Brown wrote:
> > On Mon, Jan 27, 2014 at 09:34:49AM +0100, Jean-Francois Moine wrote:
> > > + - audio-ports: one or two values.
> > > + The first value defines the I2S input port.
> > > + The second one, if present, defines the S/PDIF input port.
> > I take it these are port numbers on the device and it's not possible to
> > do something like having multiple I2S ports?
> You can feed it with multiple synchronised I2S streams for the additional
> channels.
Ah, I feared as much. The bindings ought to take account of that
posibility even if the code can't use additional ports yet. Perhaps
separate properties for I2S and S/PDIF?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140127/5b441d2e/attachment.sig>
^ permalink raw reply
* [PATCH 2/3] ASoC: atmel_wm8904: make it available to choose clock
From: Mark Brown @ 2014-01-27 20:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52D7366B.1030909@atmel.com>
On Thu, Jan 16, 2014 at 09:31:23AM +0800, Bo Shen wrote:
> >Shouldn't this code be in the DAI driver? Otherwise this series looks
> >fine to me, though the DT folks might have something to say I guess.
> For audio on Atmel SoC, it depends on three device nodes, one is
> SSC node, one is the codec node and the sound node.
> The sound node will parse by machine driver, and machine driver is
> mainly for hardware connection. As the "clk_from_rk_pin" is decided
> by hardware, so, I put it here.
> If I move the code to dai driver, it will parse the sound node in
> dai driver, I think it will make the code a little bit not explicit.
> What do you think?
I think it should just be a property of the DAI device. It's true that
the card defines the connections but if something is going to be an
option that's there for most if not all systems then putting it in the
device driver means less effort on each integration.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140127/2940e34c/attachment.sig>
^ permalink raw reply
* [RFC] drivers: irq-chip: Enable SGI's for Secure-to-NonSecure communication use-cases
From: Bill Pringlemeir @ 2014-01-27 21:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <79CD15C6BA57404B839C016229A409A83EDAD85E@DBDE04.ent.ti.com>
> From: Russell King - ARM Linux [mailto:linux at arm.linux.org.uk]
>> So it seems that your intention is to use the existing infrastructure
>> for this by directing SGIs through the normal IRQ processing.
>> To that idea, I say no way.
On 6 Jan 2014, hvaibhav at ti.com wrote:
> You have any other alternative?
I think you need to put Bhupesh Sharma's comment with this. The typical
sane mode for GIC with TZ is to have the monitor mode toggle the IRQ/FIQ
routing bits in the SCR (cp15) bits 1,2. That is, the IRQ goes direct
to core and FIQ goes to monitor from the 'Normal' world. In the
'Secure' world, the FIQ goes direct to core and IRQ traps to monitor.
The monitor mode vector table has a gateway from secure to normal for
IRQ and gateway from normal to secure for FIQ.
Now, consider the 'SMC' instruction and what is present in stuff like
this,
http://lwn.net/Articles/513756/
mach-omap2/{omap-smc.S,omap-secure.c,omap-secure.h}
Instead of messing around with the GIC, why not use something even more
generic like the 'SMC' instruction. It has the same sort of 'end game'
which is a trap to monitor mode. The monitor has to be a little smarter
to determine which world called but this should always be the case;
really you want to check this.
Btw, the situation is the same no matter which world Linux is in. I
don't think Linux can be the recipient of an 'SMC' call. But I think
most use cases would put it in the 'normal world' and the SMC is fine.
Fwiw,
Bill Pringlemeir.
^ permalink raw reply
* [PATCH] arm64: Add pdev_archdata for dmamask
From: Yann Droneaud @ 2014-01-27 21:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127203635.GA15937@n2100.arm.linux.org.uk>
Hi Russel,
Le lundi 27 janvier 2014 ? 20:36 +0000, Russell King - ARM Linux a
?crit :
> On Mon, Jan 27, 2014 at 09:25:31PM +0100, Yann Droneaud wrote:
> > ARM, even AAAAARGH64 [1], doesn't need a special treatement regarding
> > the infamous dma_mask pointer. So perhaps my solution is better.
> >
> > This solution (adding dma_mask in pdev_archdata) is already in use in
> > powerpc architecture. See arch/powerpc/kernel/setup-common.c
> >
> > The advantage of this solution is that it makes a dma_mask placeholder
> > available to statically allocated platform_device struct, while mine
> > only address the problem for platform_device struct allocated with
> > platform_device_alloc().
>
> As I've already said in this thread, the basic problem comes from DT's
> platform device creation. It's the responsibility of the device creator
> to set the dma_mask pointer appropriately, and DT doesn't do that. So,
> DT needs to be fixed rather than everyone introducing their own
> workarounds for this.
>
Sure proliferation of fixes is not what we want.
Note that Uwe added me to the thread not because I tried to address
the same issue, but I tried to improve platform_device_register_full() to
not allocate and leak an u64 used to hold the dma mask provided as part of
platform_device_info. I believe he thought the two issues could be solved
at the same time.
> > I'm also considering using dma_set_mask_and_coherent() in
> > platform_device_register_full() and drivers using
> > platform_device_alloc().
>
> As the one who introduced dma_set_mask_and_coherent, consider this a
> strong NAK on that. The reason is dma_set_mask_and_coherent() is
> for drivers to set their requirements, not for the bus requirements
> to be set in the first place.
>
> It also means that drivers which need no DMA support are subjected to
> DMA restrictions (in that dma_set_mask_and_coherent can error out if
> the platform can't support the DMA mask.)
>
I'm not sure to understand your point here. If the driver explicitly set
a DMA mask in its call to platform_device_register_full(), can't we suppose
it should be subject to restriction from the platform ?
As I'm not sure to be clear on this particular point, here's the patch I
was considering, (sorry of being quite out of topic):
---8<---
Subject: [PATCH] driver core/platform: use dma_set_mask_and_coherent() in
platform_device_register_full()
dma_set_mask_and_coherent() is a nice function for setting the
various DMA masks in struct device. Additionnaly, it checks the
mask value against arch limits.
It may be used to control the validity of the dma_mask given to
platform_device_register_full() and setting the masks in struct
platform_device.
Note: as dma_set_mask() does nothing on m68k, or returns -EINVAL
on sparc (if PCI support not built), etc. this could break
in unpleasant ways I'm not yet able to detail ...
Cc: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: linux-m68k at lists.linux-m68k.org
Cc: "David S. Miller" <davem@davemloft.net>
Cc: sparclinux at vger.kernel.org
Signed-off-by: Yann Droneaud <ydroneaud@opteya.com>
---
drivers/base/platform.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index bc78848dd59a..ada1d366e1b6 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -446,8 +446,10 @@ struct platform_device *platform_device_register_full(
if (!pdev->dev.dma_mask)
goto err;
- *pdev->dev.dma_mask = pdevinfo->dma_mask;
- pdev->dev.coherent_dma_mask = pdevinfo->dma_mask;
+ ret = dma_set_mask_and_coherent(&pdev->dev,
+ pdevinfo->dma_mask);
+ if (ret)
+ goto err;
}
ret = platform_device_add_resources(pdev,
--
1.8.5.3
^ permalink raw reply related
* [PATCH RESEND v2 00/12] clk/exynos convert clock IDs to macros
From: Mike Turquette @ 2014-01-27 21:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1514827.Cd6xxeNpq2@amdc1227>
Quoting Tomasz Figa (2014-01-07 07:17:22)
> Hi Mike,
>
> On Tuesday 07 of January 2014 15:47:28 Andrzej Hajda wrote:
> > Hi,
> >
> > This patch set adds header files with macros defining exynos clocks.
> > Then it converts dts files and drivers to use macros instead
> > of magic numbers or enums to describe clock bindings.
> >
> > The patch set is rebased on the latest samsung-clk/samsung-next branch.
> >
> > The patches are generated by script.
> > Many clocks I have verified by hand.
> > I have also tested it successfully on exynos4 based board.
> >
> > This is the 2nd version of the patchset.
> > Changes:
> > - corrected devicetree mailing list,
> > - added comments to include/dt-bindings/clock/exynos4.h for
> > clocks present only in particular chip,
> > - added tab alignement in headers,
> > - added comment to CLK_NR_CLKS,
> > - added copyright headers,
> > - split long lines in dts,
> > - corrected example in bindings/clock/exynos5250-clock.txt, to point
> > appropriate clocks.
>
> I believe this has been already acked before, so could you still take
> it for 3.14? For now I'd merge only the patches adding headers and
> updating clock drivers to avoid merge conflicts and then after
> release of 3.14-rc1 we could early merge dts patches for 3.15.
Hi Tomasz,
Let's go ahead and merge this after 3.14-rc1. I'll take it in when that
drops and the DTS data will go in during the same merge window.
Regards,
Mike
>
> What do you think?
>
> Best regards,
> Tomasz
>
^ permalink raw reply
* [PATCH 0/2] Enable clock controllers on MSM
From: Mike Turquette @ 2014-01-27 21:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <69BE1300-36E8-400B-BD77-DB89740C10D2@codeaurora.org>
Quoting Kumar Gala (2014-01-23 13:57:58)
>
> On Jan 23, 2014, at 2:43 PM, Olof Johansson <olof@lixom.net> wrote:
>
> > On Thu, Jan 23, 2014 at 11:59 AM, Kumar Gala <galak@codeaurora.org> wrote:
> >>
> >> On Jan 23, 2014, at 11:25 AM, Kevin Hilman <khilman@linaro.org> wrote:
> >>
> >>> Stephen Boyd <sboyd@codeaurora.org> writes:
> >>>
> >>>> These patches add the clock controller nodes, enable the clock drivers
> >>>> on MSM based platforms, and hook it up enough to get the serial console
> >>>> working. This is based on the merge of Mike's clk-next branch with
> >>>> linux-next-20140116. The changes need the clk-next branch because that's
> >>>> where the DTS include files landed.
> >>>
> >>> I forgot to repond to this earlier, but I tested this on top of -next
> >>> and it gets the dragonboard booting w/mainline. Yay!
> >>>
> >>>> Perhaps this can be applied after 3.14-rc1 is out?
> >>>
> >>> Yeah, sounds good.
> >>>
> >>> Kevin
> >>
> >> We?ll need arm-soc to pull in the clk changes from Mike?s tree for that.
> >
> > They're queued for this merge window, right? If so, they'll be in -rc1
> > and the dependency will be solved before we apply the patches.
> >
>
> Yeah, they look like they are in Mike?s pull request for Linus. So hopefully they?ll show up in -rc1 (wasn?t sure if Mike intended them for 3.14 or not).
They are in the second pull request which I just sent today.
Regards,
Mike
>
> What?s the feeling about pushing DT and defconfig changes into 3.14 (or do we just queue them up for 3.15)?
>
> - k
>
> --
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
>
^ permalink raw reply
* [PATCH-next] drivers/clk: make max77686 driver bool for now
From: Mike Turquette @ 2014-01-27 21:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1390505535-30229-1-git-send-email-paul.gortmaker@windriver.com>
Quoting Paul Gortmaker (2014-01-23 11:32:15)
> Commit 3966c947f45911e093114371462687134d5e8d40 ("clk: max77686:
> Refactor driver data handling") added a call to __clk_get_hw()
> but this function is not exported (as __<name> is typically a
> private/internal thing).
>
> Hence this driver fails to build modular, and has been causing
> allmodconfig build breakage in arch outside of just ARM. Since
> the only defconfig that uses it sets it as =y, lets just make
> it non-modular for now.
>
> Mike says that changes are pending to export similar functionality
> in the future[1], so at that point in time, it can be returned to
> tristate if desired.
Hi Paul,
I've just sent off my 2nd pull request for 3.14 and it includes the
export for __clk_get_hw.
Regards,
Mike
>
> [1] https://lkml.org/lkml/2014/1/20/21
>
> Reported-by: SeongJae Park <sj38.park@gmail.com>
> Cc: SeongJae Park <sj38.park@gmail.com>
> Cc: Tomasz Figa <t.figa@samsung.com>
> Cc: Kyungmin Park <kyungmin.park@samsung.com>
> Cc: Mike Turquette <mturquette@linaro.org>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index efb508a..009fb9b 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -40,7 +40,7 @@ config COMMON_CLK_VERSATILE
> - Versatile Express
>
> config COMMON_CLK_MAX77686
> - tristate "Clock driver for Maxim 77686 MFD"
> + bool "Clock driver for Maxim 77686 MFD"
> depends on MFD_MAX77686
> ---help---
> This driver supports Maxim 77686 crystal oscillator clock.
> --
> 1.8.5.2
>
^ permalink raw reply
* [BUG] FL1009: xHCI host not responding to stop endpoint command.
From: Arnaud Ebalard @ 2014-01-27 22:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140123110914.GA22913@1wt.eu>
Hi Willy,
Willy Tarreau <w@1wt.eu> writes:
>> > I don't know if it should have included FL1009, it was just a guess,
>> > based on the fact that the 0x1000 and 0x1400 devices did need MSI
>> > disabled. I can attempt to ask the Fresco Logic folks I know, but I'm
>> > not sure if/when I'll get a response back.
>> >
>> > That still doesn't necessarily rule out MSI issues in the Marvell PCI
>> > host controller code. Can you attach another PCI device with MSI
>> > support under the host and see if it works?
>>
>> The various Armada-based devices I have are NAS which do not have PCIe
>> slots to plug additional devices (everything is soldered). I don't know
>> which device Thomas used for its tests. Just in case, I also added Willy
>> in CC: who have various boards and may also have done more test with
>> additional PCIe devices and CONFIG_PCI_MSI enabled on 3.13 kernel.
>
> I've been running an intel i350 dual-port NIC (igb driver) supporting
> MSI on the mirabox, and it used to work in 3.10+many of the patches
> coming from the Free-electrons team. Some recent changes to the PCI
> code introduced a regression preventing this driver from correctly
> registering an MSI interrupt, and I did not have enough time to
> investigate it deep enough to fix it. That said, I know how to hack
> it to work again, so if it can be of any use, I can run a test on
> the mirabox (armada370) and on the XPGP board (armadaXP).
Thanks for the proposal, Willy. I guess Thomas can tell better than me
what kind of tests would help ruling out a problem in MSI support and
put the blame on FL chip ;-) Thomas, if you need me to test something on
some of my platforms, do not hesitate.
Cheers,
a+
^ permalink raw reply
* [PATCH-next] drivers/clk: make max77686 driver bool for now
From: Paul Gortmaker @ 2014-01-27 22:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140127215257.4167.26286@quantum>
On 14-01-27 04:52 PM, Mike Turquette wrote:
> Quoting Paul Gortmaker (2014-01-23 11:32:15)
>> Commit 3966c947f45911e093114371462687134d5e8d40 ("clk: max77686:
>> Refactor driver data handling") added a call to __clk_get_hw()
>> but this function is not exported (as __<name> is typically a
>> private/internal thing).
>>
>> Hence this driver fails to build modular, and has been causing
>> allmodconfig build breakage in arch outside of just ARM. Since
>> the only defconfig that uses it sets it as =y, lets just make
>> it non-modular for now.
>>
>> Mike says that changes are pending to export similar functionality
>> in the future[1], so at that point in time, it can be returned to
>> tristate if desired.
>
> Hi Paul,
>
> I've just sent off my 2nd pull request for 3.14 and it includes the
> export for __clk_get_hw.
Sounds good ; I wasn't too partial to how it got fixed, but just
wanting to see the ARCH != ARM build fallout go away.
Thanks,
Paul.
--
>
> Regards,
> Mike
>
>>
>> [1] https://lkml.org/lkml/2014/1/20/21
>>
>> Reported-by: SeongJae Park <sj38.park@gmail.com>
>> Cc: SeongJae Park <sj38.park@gmail.com>
>> Cc: Tomasz Figa <t.figa@samsung.com>
>> Cc: Kyungmin Park <kyungmin.park@samsung.com>
>> Cc: Mike Turquette <mturquette@linaro.org>
>> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
>>
>> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
>> index efb508a..009fb9b 100644
>> --- a/drivers/clk/Kconfig
>> +++ b/drivers/clk/Kconfig
>> @@ -40,7 +40,7 @@ config COMMON_CLK_VERSATILE
>> - Versatile Express
>>
>> config COMMON_CLK_MAX77686
>> - tristate "Clock driver for Maxim 77686 MFD"
>> + bool "Clock driver for Maxim 77686 MFD"
>> depends on MFD_MAX77686
>> ---help---
>> This driver supports Maxim 77686 crystal oscillator clock.
>> --
>> 1.8.5.2
>>
^ permalink raw reply
* [Q] block / zynq: DMA bouncing
From: Guennadi Liakhovetski @ 2014-01-27 22:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E69E1E.3020202@monstr.eu>
Hi Michal, Russell,
On Mon, 27 Jan 2014, Michal Simek wrote:
> On 01/27/2014 06:52 PM, Russell King - ARM Linux wrote:
> > On Mon, Jan 27, 2014 at 06:45:50PM +0100, Michal Simek wrote:
> >> Why 0x4000? IRC Linux for ARM is using space for any purpose.
> >> Russell knows this much better than I.
> >
> > Probably because as the kernel is loaded at 0x8000, it will place the
> > swapper page table at 0x4000, thus covering from 0x4000 upwards.
>
> Ah yeah swapper.
>
> >
> > Thus, the majority of your un-DMA-able memory will be kernel text or
> > swapper page tables.
>
> Yes, exactly.
> 0x0 - 0x4000 - reserving not to be used by DMA
> 0x4000 - 0x8000 swapper page table
> 0x8000 - 0x80000 kernel text + up
Good, thanks for the explanations and examples, we'll do the same then!
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* [RFC PATCH V2 1/4] pci: APM X-Gene PCIe controller driver
From: Tanmay Inamdar @ 2014-01-27 22:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5086198.ZOWZ5xuyna@wuerfel>
On Sat, Jan 25, 2014 at 12:11 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 24 January 2014 13:28:22 Tanmay Inamdar wrote:
>> On Thu, Jan 16, 2014 at 5:10 PM, Tanmay Inamdar <tinamdar@apm.com> wrote:
>> > On Wed, Jan 15, 2014 at 4:39 AM, Arnd Bergmann <arnd@arndb.de> wrote:
>> >> On Wednesday 15 January 2014, Tanmay Inamdar wrote:
>
>> >>
>> >>> +static void xgene_pcie_poll_linkup(struct xgene_pcie_port *port, u32 *lanes)
>> >>> +{
>> >>> + void *csr_base = port->csr_base;
>> >>> + u32 val32;
>> >>> + u64 start_time, time;
>> >>> +
>> >>> + /*
>> >>> + * A component enters the LTSSM Detect state within
>> >>> + * 20ms of the end of fundamental core reset.
>> >>> + */
>> >>> + msleep(XGENE_LTSSM_DETECT_WAIT);
>> >>> + port->link_up = 0;
>> >>> + start_time = jiffies;
>> >>> + do {
>> >>> + val32 = readl(csr_base + PCIECORE_CTLANDSTATUS);
>> >>> + if (val32 & LINK_UP_MASK) {
>> >>> + port->link_up = 1;
>> >>> + port->link_speed = PIPE_PHY_RATE_RD(val32);
>> >>> + val32 = readl(csr_base + BRIDGE_STATUS_0);
>> >>> + *lanes = val32 >> 26;
>> >>> + }
>> >>> + time = jiffies_to_msecs(jiffies - start_time);
>> >>> + } while ((!port->link_up) || (time <= XGENE_LTSSM_L0_WAIT));
>> >>> +}
>> >>
>> >> Maybe another msleep() in the loop? It seems weird to first do an
>> >> unconditional sleep but then busy-wait for the result.
>> >
>> > ok.
>>
>> This loop can execute for maximum 4 msec. So putting msleep(1) won't
>> get us much.
>
> 4 msec is still quite a long time for a busy loop that can be spent doing
> useful work in another thread.
>
Right. If 'msleep(1)' is used, then 'checkpatch' throws a warning
saying that it can actually sleep for 20ms in some cases. I will check
if 'usleep_range' is useful here.
>> >>
>> >> Another general note: Your "compatible" strings are rather unspecific.
>> >> Do you have a version number for this IP block? I suppose that it's related
>> >> to one that has been used in other chips before, or will be used in future
>> >> chips, if it's not actually licensed from some other company.
>> >
>> > I will have to check this.
>> >
>>
>> We have decided to stick with current compatible string for now.
>
> Can you elaborate on your reasoning? Does this mean X-Gene is a one-off
> product and you won't be doing any new chips based on the same hardware
> components?
The current convention is to key upon the family name - X-Gene. Future
chips will also be a part of X-Gene family. Right now it is unclear if
there are any obvious feature additions to be done in Linux PCIe
driver. Until then same driver is expected to work as is in future
chips.
>
> Arnd
^ permalink raw reply
* [RFC PATCH V3 0/4] APM X-Gene PCIe controller
From: Tanmay Inamdar @ 2014-01-27 22:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CALdTtnsEo74UeYgoQ0DF7=LN074b_0bL0vg6Bxs02B9nDkRTNA@mail.gmail.com>
On Sat, Jan 25, 2014 at 8:09 AM, Dann Frazier
<dann.frazier@canonical.com> wrote:
> On Fri, Jan 24, 2014 at 2:32 PM, Tanmay Inamdar <tinamdar@apm.com> wrote:
>> This patch adds support for AppliedMicro X-Gene PCIe host controller. The
>> driver is tested on X-Gene platform with different gen1/2/3 PCIe endpoint
>> cards.
>>
>> X-Gene PCIe controller driver has depedency on the pcie arch support for
>> arm64. The arm64 pcie arch support is not yet part of mainline Linux kernel
>> and approach for arch support is under discussion with arm64 maintainers.
>> The reference patch can be found here --> https://lkml.org/lkml/2013/10/23/244
>
> The reference patch looks corrupted (pcibios.c has no includes, etc),
> would you mind reposting?
Yes. You are right. I will re-post the patch.
>
> -dann
>
>> If someone wishes to test PCIe on X-Gene, arch support patch must be applied
>> before the patches in this patch set.
>>
>> changes since V2:
>> 1. redefined each PCI port in different PCI domain correctly.
>> 2. removed setup_lane and setup_link functions from driver.
>> 3. removed scan_bus wrapper and set_primary_bus hack.
>> 4. added pci_ioremap_io for io resources.
>>
>> changes since V1:
>> 1. added PCI domain support
>> 2. reading cpu and pci addresses from device tree to configure regions.
>> 3. got rid of unnecessary wrappers for readl and writel.
>> 4. got rid of endpoint configuration code.
>> 5. added 'dma-ranges' property support to read inbound region configuration.
>> 6. renamed host driver file to 'pci-xgene.c' from 'pcie-xgene.c'
>> 7. dropped 'clock-names' property from bindings
>> 8. added comments whereever requested.
>>
>> Tanmay Inamdar (4):
>> pci: APM X-Gene PCIe controller driver
>> arm64: dts: APM X-Gene PCIe device tree nodes
>> dt-bindings: pci: xgene pcie device tree bindings
>> MAINTAINERS: entry for APM X-Gene PCIe host driver
>>
>> .../devicetree/bindings/pci/xgene-pci.txt | 52 ++
>> MAINTAINERS | 7 +
>> arch/arm64/boot/dts/apm-mustang.dts | 8 +
>> arch/arm64/boot/dts/apm-storm.dtsi | 155 ++++
>> drivers/pci/host/Kconfig | 10 +
>> drivers/pci/host/Makefile | 1 +
>> drivers/pci/host/pci-xgene.c | 784 ++++++++++++++++++++
>> 7 files changed, 1017 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/pci/xgene-pci.txt
>> create mode 100644 drivers/pci/host/pci-xgene.c
>>
>> --
>> 1.7.9.5
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> the body of a message to majordomo at vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Samsung-clk patches for 3.15
From: Tomasz Figa @ 2014-01-27 23:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52E27AE9.7040501@samsung.com>
[Forgot to Cc Mike...]
On 24.01.2014 15:38, Tomasz Figa wrote:
> Hi,
>
> Linux 3.14 is going to include Andrzej Hajda's patches converting
> Samsung clock drivers to use clock ID defines in include/dt-bindings,
> instead of local enums, but to avoid unnecessary merge conflicts we have
> converted only the clock driver, leaving DTS files unchanged yet.
>
> We intend to complete the conversion in 3.15, by replacing magic numbers
> in DTS files with respective preprocessor macros, but to reduce
> potential conflicts we need help of you, Samsung clock patches authors :).
>
> I'd like to ask anybody who already has patches for DTS files adding any
> clock-related contents still using numeric IDs, e.g. clock properties in
> nodes or full nodes containing clock properties, to make sure that the
> patches are merged before Andrzej sends the conversion patches. Then
> Andrzej's script will generate patches updating all clock properties,
> leaving no numeric IDs in DTS files.
>
> If you are just starting your work on a patch that introduces changes as
> mentioned above, please make sure to already use clock macros, not
> numeric IDs. Otherwise you risk having needless rebases with a lot of
> conflicts. You have been warned ;).
>
> Best regards,
> Tomasz
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox