* [PATCH 1/3] atmel_lcdfb: fix 16-bpp modes on older SOCs
From: Jean-Christophe PLAGNIOL-VILLARD @ 2013-01-29 13:54 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1355142530-10366-2-git-send-email-jhovold@gmail.com>
On 13:28 Mon 10 Dec , Johan Hovold wrote:
> Fix regression introduced by commit 787f9fd23283 ("atmel_lcdfb: support
> 16bit BGR:565 mode, remove unsupported 15bit modes") which broke 16-bpp
> modes for older SOCs which use IBGR:555 (msb is intensity) rather
> than BGR:565.
>
> Use SOC-type to determine the pixel layout.
>
> Tested on custom at91sam9263-board.
>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Johan Hovold <jhovold@gmail.com>
> ---
> drivers/video/atmel_lcdfb.c | 22 +++++++++++++++-------
> include/video/atmel_lcdc.h | 1 +
> 2 files changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
> index 1505539..1f68fa6 100644
> --- a/drivers/video/atmel_lcdfb.c
> +++ b/drivers/video/atmel_lcdfb.c
> @@ -422,17 +422,22 @@ static int atmel_lcdfb_check_var(struct fb_var_screeninfo *var,
> = var->bits_per_pixel;
> break;
> case 16:
> + /* Older SOCs use IBGR:555 rather than BGR:565. */
> + if (sinfo->have_intensity_bit)
> + var->green.length = 5;
> + else
> + var->green.length = 6;
> +
> if (sinfo->lcd_wiring_mode == ATMEL_LCDC_WIRING_RGB) {
> - /* RGB:565 mode */
> - var->red.offset = 11;
> + /* RGB:5X5 mode */
> + var->red.offset = var->green.length + 5;
> var->blue.offset = 0;
> } else {
> - /* BGR:565 mode */
> + /* BGR:5X5 mode */
> var->red.offset = 0;
> - var->blue.offset = 11;
> + var->blue.offset = var->green.length + 5;
> }
> var->green.offset = 5;
> - var->green.length = 6;
> var->red.length = var->blue.length = 5;
> break;
> case 32:
> @@ -679,8 +684,7 @@ static int atmel_lcdfb_setcolreg(unsigned int regno, unsigned int red,
>
> case FB_VISUAL_PSEUDOCOLOR:
> if (regno < 256) {
> - if (cpu_is_at91sam9261() || cpu_is_at91sam9263()
> - || cpu_is_at91sam9rl()) {
> + if (sinfo->have_intensity_bit) {
> /* old style I+BGR:555 */
> val = ((red >> 11) & 0x001f);
> val |= ((green >> 6) & 0x03e0);
> @@ -870,6 +874,10 @@ static int __init atmel_lcdfb_probe(struct platform_device *pdev)
> }
> sinfo->info = info;
> sinfo->pdev = pdev;
> + if (cpu_is_at91sam9261() || cpu_is_at91sam9263() ||
> + cpu_is_at91sam9rl()) {
> + sinfo->have_intensity_bit = true;
> + }
nack
you need to drop the cpu_is as this can only be use now for the core
use platform_device_id to indetify the IP as done on at91-i2c as we can not
detect the IP version
Best Regards,
J.
>
> strcpy(info->fix.id, sinfo->pdev->name);
> info->flags = ATMEL_LCDFB_FBINFO_DEFAULT;
> diff --git a/include/video/atmel_lcdc.h b/include/video/atmel_lcdc.h
> index 28447f1..5f0e234 100644
> --- a/include/video/atmel_lcdc.h
> +++ b/include/video/atmel_lcdc.h
> @@ -62,6 +62,7 @@ struct atmel_lcdfb_info {
> void (*atmel_lcdfb_power_control)(int on);
> struct fb_monspecs *default_monspecs;
> u32 pseudo_palette[16];
> + bool have_intensity_bit;
> };
>
> #define ATMEL_LCDC_DMABADDR1 0x00
> --
> 1.8.0
>
^ permalink raw reply
* [PATCH 08/10] ARM: OMAP5: hwmod data: Create initial OMAP5 SOC hwmod data
From: Santosh Shilimkar @ 2013-01-29 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122183213.GN15361@atomide.com>
On Wednesday 23 January 2013 12:02 AM, Tony Lindgren wrote:
> * Benoit Cousson <b-cousson@ti.com> [130122 04:59]:
>> Hi Tony,
>>
>> On 01/21/2013 07:01 PM, Tony Lindgren wrote:
>>> * Santosh Shilimkar <santosh.shilimkar@ti.com> [130121 07:09]:
>>>>>
>>>> So I looked at this one with help of Rajendra. We can get rid of the
>>>> IRQ and DMA data(needs DMA biding updates) easily. The address
>>>> space though is needed since hwmod code uses it to setup the
>>>> sysconfig registers.
>>>
>>> OK great. The address space tinkering in hwmod code should be
>>> moved to be done in the drivers.
>>>
>>> As discussed earlier, there should be a driver specific reset
>>> function driver_xyz_reset() in the driver header file so the
>>> hwmod code can call it too in a late_initcall if no driver is
>>> loaded.
>>>
>>>> Extracting that from DT code seems to be really expensive and
>>>> ugly [1]. I am yet to try out DMA lines removal but that seems
>>>> to be doable by pulling Vinod'd DMA engine branch and updating
>>>> DT file.
>>>
>>> The overhead here does not matter as it should only happen in a
>>> late_initcall and only for some of the drivers. For that to
>>> happen we just need to go through the list of modules not yet
>>> probed. We also need to have some locking in the driver specific
>>> reset function to avoid races with the loadable modules.
>>
>> Mmm, not really, that address is used by *every* hwmod for sysconfig
>> access. So iterating over every DT nodes for every hwmods seems pretty
>> ugly and un-optimized.
>
> I think you missed one point. Iterating over all the modules should
> only happen for the unused modules. With sysconfig access moved to the
> drivers getting the ioaddress is done in the standard way in the driver
> probe instead of iterating over all of them.
>
>> That being said, it might worth checking the overhead. That will not
>> make the fix nicer anyway, but at least it will allow a smooth
>> transition toward a real clean solution. Assuming someone will work on
>> that later, which might never happen.
>
> Right, so who is going to do all the work needed?
>
OK so we do managed to clean up the address space, IRQ lines
and DMA request lines data from hwmod completely.
-OMAP5 hwmod data file, 2076 lines we could remove which significant
reduction. I ran the same scripts on OMAP4 and there too about 2200
lines getting deleted.
- I have to udapte DT file to add the all supported hwmods with reg
property so that OMAP5 continue to boot. Similar work is needed for
OMAP4 too once OMAP4 is made DT only support.
- To my suprise, the DT lookup isn't that bad. It is adding just
24 milliseconds to the boot time which is more or less noise.
Have pushed a branch with above update for OMAP5 here [1]
So we are left with two other topics which you mentioned in the
comments.
1. Movement of clock data to drivers/clk. Till we get direction here
I would like to hear the alternative to get OMAP5 booting from mainline.
If there is no alternative, we can keep OMAP5 clock data alone
out of tree and get rest of the data files merged.
2. The iormap() done by hwmod for sysconfig handling which you are
discussing with Rajendra. So far we don't have a viable way to
get the iormapped address from device drivers back to platform
code. Lets continue on this thread but this can evolve in
parallel.
Let me know your thoughts.
Regards,
Santosh
[1] git://github.com/SantoshShilimkar/linux.git
3.9/omap5-testing-hwmod-cleanup
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Andrew Murray @ 2013-01-29 14:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129144522.44ed7373@skate>
On Tue, Jan 29, 2013 at 01:45:22PM +0000, Thomas Petazzoni wrote:
> Dear Andrew Murray,
>
> On Tue, 29 Jan 2013 13:22:04 +0000, Andrew Murray wrote:
>
> > > +static int __init mvebu_pcie_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
> > > +{
> >
> > [snip]
> >
> > > +
> > > + /*
> > > + * Build an laddr array that describes the PCI device in a DT
> > > + * way
> > > + */
> > > + laddr[0] = cpu_to_be32(port->devfn << 8);
> > > + laddr[1] = laddr[2] = 0;
> > > + intspec = cpu_to_be32(pin);
> > > +
> > > + ret = of_irq_map_raw(port->dn, &intspec, 1, laddr, &oirq);
> > > + if (ret) {
> > > + dev_err(&pcie->pdev->dev,
> > > + "%s: of_irq_map_raw() failed, %d\n",
> > > + __func__, ret);
> > > + return ret;
> > > + }
> >
> > Are you able to replace the above code with a call to of_irq_map_pci? I'm not
> > sure which approach is better. The of_irq_map_pci function doesn't require the
> > pin argument and instead uses the DT and/or performs its own pin swizzling. I
> > guess this means that if there are PCIe devices in the DT tree that does any
> > thing strange with pins then it would be reflected in the IRQ you get. I've
> > found that you will also need to provide an implementation of
> > pcibios_get_phb_of_node for this to work correctly (see my RFC bios32 patch).
>
> I did try using the of_irq_map_pci() function, but unfortunately, it
> didn't work. IIRC, it didn't work because none of the pci_dev in my PCI
> tree had any 'struct device_node' associated to them, or at least not
> the one that had the right pdev->bus->number and pdev->devfn.
>
> But, I guess that your patch that implements pcibios_get_phb_of_node()
> should fix this problem. I'll try this. Thanks!
My bios32 patch departs slightly from your v2 04/27 patch in that it updates
hw_pci to contain a device node rather than opaque private data and my
pcibios_get_phb_of_node implementation relies on this. If you wanted to stick
with the implementation you and Thierry share then you'd have to find another
way to get to the device node from the void **private_data.
> > > +static int mvebu_pcie_init(void)
> > > +{
> > > + return platform_driver_probe(&mvebu_pcie_driver,
> > > + mvebu_pcie_probe);
> > > +}
> >
> > If you have multiple 'mvebu-pcie' in your DT then you will end up
> > with multiple calls to
> > mvebu_pcie_probe/mvebu_pcie_enable/pci_common_init.
>
> Right. In practice, there will only ever be a single DT node, since all
> PCIe interfaces are sub-nodes of the PCI controller node. But I
> understand the theoretical problem.
>
> > However pci_common_init/pcibios_init_hw assumes it will only ever be called
> > once, and will thus result in trying to create multiple busses with the same
> > bus number. (The first root bus it creates is always zero provided you haven't
> > implemented hw->scan).
> >
> > I noticed this in Thierry's patch set and posted an RFC patch which overcomes
> > this issue (patchwork.kernel.org/patch/2001171) and others. Perhaps you would
> > want to include this in your patchset?
>
> Sure, I'll give it a test, and report if it works for me.
>
> Thanks a lot!
>
> Thomas
> --
> Thomas Petazzoni, Free Electrons
> Kernel, drivers, real-time and embedded Linux
> development, consulting, training and support.
> http://free-electrons.com
>
^ permalink raw reply
* [PATCH,RFC] usb: add devicetree helpers for determining dr_mode and phy_type
From: kishon @ 2013-01-29 14:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129135336.GA3323@pengutronix.de>
On Tuesday 29 January 2013 07:23 PM, Wolfram Sang wrote:
>>> + err = of_property_read_string(np, "phy_type", &phy_type);
>>> + if (err < 0)
>>> + return USBPHY_INTERFACE_MODE_NA;
>>
>> Why don't we use a u32 property type for the *phy-type*? IMHO we
>> should use string property only when the property should be
>> absolutely unambiguous (e.g., compatible property should be string).
>
> If we would use u32-numbers in the compatible entry, this would also be
> unambiguous, no? 0xd00dfeed would be the at24-driver. Pretty specific.
hehe... But we don't have a corresponding *enum* representing the
drivers :-)
>
> I don't mind having readable devicetrees. And we have it for ethernet
> phys already with strings, so it would be consistent.
Ok. Fine with it then :-)
Thanks
Kishon
^ permalink raw reply
* [RFC] arm: use built-in byte swap function
From: Russell King - ARM Linux @ 2013-01-29 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128193033.8a0b0a871150c99247f05a95@freescale.com>
On Mon, Jan 28, 2013 at 07:30:33PM -0600, Kim Phillips wrote:
> AFAICT, arm gcc got __builtin_bswap{32,64} support in 4.6,
> and for the 16-bit version in 4.8.
Hmm.
$ /usr/local/aeabi/bin/arm-linux-gcc --version
arm-linux-gcc (GCC) 4.5.4
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ for a in armv3 armv4 armv4t armv5t armv5te armv6k armv6 armv7-a; do \
echo $a:; \
for f in 16 32 64; do \
echo 'unsigned foo(unsigned val) { return __builtin_bswap'$f'(val); }' | \
/usr/local/aeabi/bin/arm-linux-gcc -x c -S -o - - -march=$a | grep 'bl'; \
done; \
done
produces:
armv3:
bl __builtin_bswap16
armv4:
bl __builtin_bswap16
armv4t:
bl __builtin_bswap16
armv5t:
bl __builtin_bswap16
armv5te:
bl __builtin_bswap16
armv6k:
bl __builtin_bswap16
armv6:
bl __builtin_bswap16
armv7-a:
bl __builtin_bswap16
So, this compiler (4.5.4) has support for 32-bit and 64-bit bswaps
across all our architectures, but not the 16-bit ones.
^ permalink raw reply
* [GIT PULL] imx cleanup for 3.9
From: Olof Johansson @ 2013-01-29 14:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129072603.GL1906@pengutronix.de>
On Tue, Jan 29, 2013 at 08:26:03AM +0100, Sascha Hauer wrote:
> On Tue, Jan 29, 2013 at 09:08:55AM +0800, Shawn Guo wrote:
> > On Mon, Jan 28, 2013 at 02:00:26PM -0800, Olof Johansson wrote:
> > > Hi,
> > >
> > > On Tue, Jan 22, 2013 at 10:48:15PM +0800, Shawn Guo wrote:
> > >
> > > > Shawn Guo (4):
> > > > ARM: dts: imx: use nodes label in board dts
> > >
> > > Hmm.
> > >
> > > This patch is 1000 lines of pure churn. Sure, the style on OMAP is different,
> > > but there's no clear benefit from it -- it's actually advantageous to see some
> > > of the bus hierarchies even on the leaf-level board nodes.
> > >
> > > Would you mind respinning with this left out, please? If you still want to
> > > argue it to be included, we can do so, but I'd like to pick up the rest of the
> > > branch meanwhile. :-)
> >
> > I will refresh the pull-request to leave it out, but meanwhile I'd like
> > to argue too, as the approach has been agreed by IMX people and all the
> > patches I queued on imx/dt are all in this way. And I will move the
> > patch to imx/dt branch instead, if you're not strongly against the
> > approach.
> >
> > The board level dts are mostly used to add/overwrite properties for
> > nodes defined in soc dts. Therefore, what people who look at board
> > dts care about is those properties, not really which bus the nodes
> > are on. We go this way to have board dts focus on the things they
> > are created for. It's much easer to read and edit those properties.
> >
> > I'm not sure why it's important to maintain the bus topology in board
> > dts while we have the full one in soc dts. In the current way, people
> > sometimes have to reassemble 3 or more levels bus hierarchies for only
> > overwriting one property for one node.
> >
> > I'm pretty sure that people who work on board level dts would vote for
> > this way. It makes their life easier without increasing the
> > maintainer's burden. So why not?
>
> I'm with Shawn here. With this board layout I'm now able to write board
> dts files without looking much at the dtsi file at all. It's debatable
> if existing boards have to be changed to use this layout, but since
> people copy-paste all the time changing it increases the chance they
> copy the right stuff.
Ok. Just to make clear: While I personally prefer the regular way of specifying
the board dts files, my main concern with this patch is that it is _pure
churn_. It's 1000 lines of change without a functional benefit, and without
really being a cleanup that benefits long-term development.
We're starting to get more comments about the volume of churn again (Linus made
a couple of them the last merge window), and I'd rather be a bit more
conservative on some of the larger changes that lack strong benefit for
a release or two, than have him get ticked off and make life miserable for all
of us.
So, I'm not saying that it's a bad idea to change to labels, but I would rather
hold off this while we give some of the remaining platforms still not
multiplatform-enabled a chance to "use the churn quota" since they will need it
for include file moves, etc, etc.
-Olof
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Thierry Reding @ 2013-01-29 14:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129140522.GA24310@arm.com>
On Tue, Jan 29, 2013 at 02:05:22PM +0000, Andrew Murray wrote:
> On Tue, Jan 29, 2013 at 01:45:22PM +0000, Thomas Petazzoni wrote:
> > Dear Andrew Murray,
> >
> > On Tue, 29 Jan 2013 13:22:04 +0000, Andrew Murray wrote:
> >
> > > > +static int __init mvebu_pcie_map_irq(const struct pci_dev *dev, u8 slot, u8 pin)
> > > > +{
> > >
> > > [snip]
> > >
> > > > +
> > > > + /*
> > > > + * Build an laddr array that describes the PCI device in a DT
> > > > + * way
> > > > + */
> > > > + laddr[0] = cpu_to_be32(port->devfn << 8);
> > > > + laddr[1] = laddr[2] = 0;
> > > > + intspec = cpu_to_be32(pin);
> > > > +
> > > > + ret = of_irq_map_raw(port->dn, &intspec, 1, laddr, &oirq);
> > > > + if (ret) {
> > > > + dev_err(&pcie->pdev->dev,
> > > > + "%s: of_irq_map_raw() failed, %d\n",
> > > > + __func__, ret);
> > > > + return ret;
> > > > + }
> > >
> > > Are you able to replace the above code with a call to of_irq_map_pci? I'm not
> > > sure which approach is better. The of_irq_map_pci function doesn't require the
> > > pin argument and instead uses the DT and/or performs its own pin swizzling. I
> > > guess this means that if there are PCIe devices in the DT tree that does any
> > > thing strange with pins then it would be reflected in the IRQ you get. I've
> > > found that you will also need to provide an implementation of
> > > pcibios_get_phb_of_node for this to work correctly (see my RFC bios32 patch).
> >
> > I did try using the of_irq_map_pci() function, but unfortunately, it
> > didn't work. IIRC, it didn't work because none of the pci_dev in my PCI
> > tree had any 'struct device_node' associated to them, or at least not
> > the one that had the right pdev->bus->number and pdev->devfn.
> >
> > But, I guess that your patch that implements pcibios_get_phb_of_node()
> > should fix this problem. I'll try this. Thanks!
>
> My bios32 patch departs slightly from your v2 04/27 patch in that it updates
> hw_pci to contain a device node rather than opaque private data and my
> pcibios_get_phb_of_node implementation relies on this. If you wanted to stick
> with the implementation you and Thierry share then you'd have to find another
> way to get to the device node from the void **private_data.
If at all possible I think the right thing to do is reuse the generic
pcibios_get_phb_of_node() implementation. On Tegra this turned out to
require a minimal change to the DT bindings of the root port nodes to
make sure they provide the correct address in the reg property.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130129/47c1c5ce/attachment.sig>
^ permalink raw reply
* [PATCH 1/5] dmaengine: dw_dmac: move to generic DMA binding
From: Russell King - ARM Linux @ 2013-01-29 14:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301291344.11066.arnd@arndb.de>
On Tue, Jan 29, 2013 at 01:44:10PM +0000, Arnd Bergmann wrote:
> Can you give an example for this? We were careful to make sure it
> works with platforms that connect a slave to multiple dma engines,
> out of which any could be used for a given transfer. In the device
> tree binding, you specify all possible controllers and give the
> alternatives the same name, for example:
>
> serial at 10000000 {
> compatible = "arm,pl011", "arm,primecell";
> dmas = <dwdma0 7 0>, <dwdma0 8 1>, <&pl330 17>, <&pl330 15>;
> dma-names = "rx", "tx", "rx", "tx;
> ...
> };
No, that's not what I mean. I mean the situation we find on Versatile
platforms:
8 3 >3
PL080 DMA --/--+--/------> FPGA Mux --/--> {bunch of off-CPU peripherals}
| 5
`--/------> {On-CPU peripherals}
This is something that I've been raising _every time_ I've been involved
with DMA engine discussions when it comes to the matching stuff, so this
is nothing new, and it's not unknown about.
What is different this time around is that I've been purposely omitted
from the discussions (like what seems to be happening more and more - I
notice that I'm no longer copied on PL011 patches despite being the
driver author, or GIC patches, or VIC patches) so this stuff doesn't
get properly considered.
But it doesn't matter anymore; I'm soo out of the loop on stuff like DT
and the like that my input would be more of a hinderence now.
^ permalink raw reply
* [PATCH 1/5] dmaengine: dw_dmac: move to generic DMA binding
From: Russell King - ARM Linux @ 2013-01-29 14:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359467140.31148.41.camel@smile>
On Tue, Jan 29, 2013 at 03:45:40PM +0200, Andy Shevchenko wrote:
> On Tue, 2013-01-29 at 13:31 +0000, Arnd Bergmann wrote:
> > On Tuesday 29 January 2013, Viresh Kumar wrote:
> > > You can still keep fargs as is and just fill them as:
> > >
> > > fargs.cfg_lo = 0;
> > >
> > > if (DMA_TO_DEV)
> > > // dest is periph
> > > fargs.cfg_hi = be32_to_cpup(dma_spec->args+0) << 11;
> > > else if (DEV_TO_DMA)
> > > // src is periph
> > > fargs.cfg_hi = be32_to_cpup(dma_spec->args+0) << 7;
> > >
> > > The field size is 4 bits.
> >
> > Ah, good. So I guess the "dma-requests" property should actually
> > be "16" then.
> >
> > Does this mean that an implicit zero request line means memory?
>
> No, it doesn't.
> When dma is doing mem2mem transfers the request line field is ignored by
> the hw.
Memory to memory transfers are dealt with using a totally different API
to the slave API. Look at the rest of the DMA engine API to see how it's
used - any channel is selected with a DMA_MEMCPY capability.
(IMHO, the MEM2MEM transfer type against the slave API should never have
been permitted.)
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Thomas Petazzoni @ 2013-01-29 14:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129142015.GA23640@avionic-0098.mockup.avionic-design.de>
Dear Thierry Reding,
On Tue, 29 Jan 2013 15:20:15 +0100, Thierry Reding wrote:
> If at all possible I think the right thing to do is reuse the generic
> pcibios_get_phb_of_node() implementation. On Tegra this turned out to
> require a minimal change to the DT bindings of the root port nodes to
> make sure they provide the correct address in the reg property.
Could you detail the change that was needed? The DT bindings I use for
the Marvell PCIe driver are very, very similar to the ones you use for
Tegra, since I basically inspired my entire DT binding on your work.
And still, I think of_irq_map_pci() wasn't working for me.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 3/5] ARM: make the platforms not to select the l2x0 erratas
From: Rob Herring @ 2013-01-29 14:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129101537.GA19817@bnru10>
On 01/29/2013 04:15 AM, srinidhi kasagar wrote:
> Make the platforms not to choose the Errata's explicitly
Why?
>
> Signed-off-by: srinidhi kasagar <srinidhi.kasagar@stericsson.com>
> ---
> arch/arm/mach-imx/Kconfig | 3 ---
> arch/arm/mach-omap2/Kconfig | 2 --
> arch/arm/mach-tegra/Kconfig | 3 ---
> arch/arm/mach-ux500/Kconfig | 1 -
> arch/arm/mach-vexpress/Kconfig | 1 -
> 5 files changed, 0 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/mach-imx/Kconfig b/arch/arm/mach-imx/Kconfig
> index 3e628fd..8ed6672 100644
> --- a/arch/arm/mach-imx/Kconfig
> +++ b/arch/arm/mach-imx/Kconfig
> @@ -855,9 +855,6 @@ config SOC_IMX6Q
> select MFD_SYSCON
> select PINCTRL
> select PINCTRL_IMX6Q
> - select PL310_ERRATA_588369 if CACHE_PL310
> - select PL310_ERRATA_727915 if CACHE_PL310
> - select PL310_ERRATA_769419 if CACHE_PL310
> select PM_OPP if PM
>
> help
> diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
> index 41b581f..7612c07 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -67,8 +67,6 @@ config ARCH_OMAP4
> select HAVE_SMP
> select LOCAL_TIMERS if SMP
> select OMAP_INTERCONNECT
> - select PL310_ERRATA_588369
> - select PL310_ERRATA_727915
> select PM_OPP if PM
> select PM_RUNTIME if CPU_IDLE
> select USB_ARCH_HAS_EHCI if USB_SUPPORT
> diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig
> index b442f15..f6214f5 100644
> --- a/arch/arm/mach-tegra/Kconfig
> +++ b/arch/arm/mach-tegra/Kconfig
> @@ -15,8 +15,6 @@ config ARCH_TEGRA_2x_SOC
> select CPU_V7
> select PINCTRL
> select PINCTRL_TEGRA20
> - select PL310_ERRATA_727915 if CACHE_L2X0
> - select PL310_ERRATA_769419 if CACHE_L2X0
> select USB_ARCH_HAS_EHCI if USB_SUPPORT
> select USB_ULPI if USB
> select USB_ULPI_VIEWPORT if USB_SUPPORT
> @@ -36,7 +34,6 @@ config ARCH_TEGRA_3x_SOC
> select CPU_V7
> select PINCTRL
> select PINCTRL_TEGRA30
> - select PL310_ERRATA_769419 if CACHE_L2X0
> select USB_ARCH_HAS_EHCI if USB_SUPPORT
> select USB_ULPI if USB
> select USB_ULPI_VIEWPORT if USB_SUPPORT
> diff --git a/arch/arm/mach-ux500/Kconfig b/arch/arm/mach-ux500/Kconfig
> index 5dea906..db13db5 100644
> --- a/arch/arm/mach-ux500/Kconfig
> +++ b/arch/arm/mach-ux500/Kconfig
> @@ -11,7 +11,6 @@ config UX500_SOC_COMMON
> select COMMON_CLK
> select PINCTRL
> select PINCTRL_NOMADIK
> - select PL310_ERRATA_753970 if CACHE_PL310
>
> config UX500_SOC_DB8500
> bool
> diff --git a/arch/arm/mach-vexpress/Kconfig b/arch/arm/mach-vexpress/Kconfig
> index 52d315b..c658c40 100644
> --- a/arch/arm/mach-vexpress/Kconfig
> +++ b/arch/arm/mach-vexpress/Kconfig
> @@ -42,7 +42,6 @@ config ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA
> bool "Enable A5 and A9 only errata work-arounds"
> default y
> select ARM_ERRATA_720789
> - select PL310_ERRATA_753970 if CACHE_PL310
> help
> Provides common dependencies for Versatile Express platforms
> based on Cortex-A5 and Cortex-A9 processors. In order to
>
^ permalink raw reply
* [PATCH,RFC] usb: add devicetree helpers for determining dr_mode and phy_type
From: Felipe Balbi @ 2013-01-29 14:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5107D84F.80401@ti.com>
Hi,
On Tue, Jan 29, 2013 at 07:40:23PM +0530, kishon wrote:
> On Tuesday 29 January 2013 07:23 PM, Wolfram Sang wrote:
> >>>+ err = of_property_read_string(np, "phy_type", &phy_type);
> >>>+ if (err < 0)
> >>>+ return USBPHY_INTERFACE_MODE_NA;
> >>
> >>Why don't we use a u32 property type for the *phy-type*? IMHO we
> >>should use string property only when the property should be
> >>absolutely unambiguous (e.g., compatible property should be string).
> >
> >If we would use u32-numbers in the compatible entry, this would also be
> >unambiguous, no? 0xd00dfeed would be the at24-driver. Pretty specific.
>
> hehe... But we don't have a corresponding *enum* representing the
> drivers :-)
> >
> >I don't mind having readable devicetrees. And we have it for ethernet
> >phys already with strings, so it would be consistent.
>
> Ok. Fine with it then :-)
I prefer u32 here, because we have the matching enum. Otherwise we end
up with:
of_property_read_string(...,&type);
if (!strcmp(type, "ulpi"))
foo();
else if (!strcmp(type, "utmi"))
bar();
else if (!strcmp(type, "pipe3"))
baz();
else
BUG();
and I don't like that, it's ugly and error prone. Also looks awful when
someone needs to change that, the diff looks messy. A u32 followed by a
switch statement looks nicer.
--
balbi
-------------- 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/20130129/bb037592/attachment.sig>
^ permalink raw reply
* [RFC] arm: use built-in byte swap function
From: Woodhouse, David @ 2013-01-29 14:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129141328.GV23505@n2100.arm.linux.org.uk>
On Tue, 2013-01-29 at 14:13 +0000, Russell King - ARM Linux wrote:
>
> So, this compiler (4.5.4) has support for 32-bit and 64-bit bswaps
> across all our architectures, but not the 16-bit ones.
That observation is consistent with my dig through GCC history. I had
come to the conclusion that the 32-bit and 64-bit versions were added
*generically* in 4.4, and that the 16-bit version was added in 4.6 to
that PowerPC back end, and made generic in 4.8. So I *had* put that
arch-specific check into compiler-gcc4.h, for PowerPC. It's just outside
the context of Kim's patch. If it really does end up being different for
every arch, I may reconsider that.
As for the __bswapsi2() calls... if it's ever emitting an out-of-line
call for something like that, that seems like a really dubious decision;
surely it's better being inlined? So rather than adding it to your
bits-of-libgcc.a in the kernel, I'd suggest just *not* using
ARCH_USE_BUILTIN_BSWAP for the offending compilers, and filing a bug to
get them fixed.
But really, this is why I created ARCH_USE_BUILTIN_BSWAP and left it to
architecture maintainers to enable it at their leisure.... :)
--
Sent with MeeGo's ActiveSync support.
David Woodhouse Open Source Technology Centre
David.Woodhouse at intel.com Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4370 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130129/301d4e82/attachment.bin>
^ permalink raw reply
* [RFC 0/3] arm: mxs: sanitize enet_out clock handling
From: Wolfram Sang @ 2013-01-29 14:46 UTC (permalink / raw)
To: linux-arm-kernel
Handling enet_out on MX28 is cumbersome at the moment. Most boards need it
enabled and for that, they have to add code to mach-mxs.c (see sps1 as an
example). Since this is board specific, we better encode it in the devicetree,
that is the reason it was made for.
My proposal will overwrite the generic "clock" and "clock-names" properties
from imx28.dtsi in the board file. The original one has 2 entries, and boards
needing enet_out will overload it with three entries. The network driver will
enable the clock if it was specified. The old code enabling the clock will be
backward compatible but print a WARN if the legacy mode needs to be used.
This will make adding new board easier, since we don't have to touch mach-mxs.c
for this case. It scales much better.
Tested on a MX28EVK. Please review, comment, apply(?)
Thanks,
Wolfram
Wolfram Sang (3):
net: freescale: fec: add support for optional enet_out clk
arm: mxs: add enet_out clock to devicetree
arm: mach-mxs: make enabling enet_out a legacy function
arch/arm/boot/dts/imx28-apf28.dts | 3 +++
arch/arm/boot/dts/imx28-apx4devkit.dts | 3 +++
arch/arm/boot/dts/imx28-cfa10049.dts | 3 +++
arch/arm/boot/dts/imx28-evk.dts | 3 +++
arch/arm/boot/dts/imx28-sps1.dts | 3 +++
arch/arm/boot/dts/imx28-tx28.dts | 3 +++
arch/arm/mach-mxs/mach-mxs.c | 24 ++++++++++++++++--------
drivers/net/ethernet/freescale/fec.c | 10 ++++++++++
drivers/net/ethernet/freescale/fec.h | 1 +
9 files changed, 45 insertions(+), 8 deletions(-)
--
1.7.10.4
^ permalink raw reply
* [RFC 1/3] net: freescale: fec: add support for optional enet_out clk
From: Wolfram Sang @ 2013-01-29 14:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359470773-14290-1-git-send-email-w.sang@pengutronix.de>
Some MX28 boards need the internal enet_out clock to be enabled. So, do
this in the driver iff the clock was referenced via devicetree.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
---
davidm: Please don't apply before Shawn as the mxs-maintainer has given his ack
on the general procedure. Or maybe he can merge it via his tree?
drivers/net/ethernet/freescale/fec.c | 10 ++++++++++
drivers/net/ethernet/freescale/fec.h | 1 +
2 files changed, 11 insertions(+)
diff --git a/drivers/net/ethernet/freescale/fec.c b/drivers/net/ethernet/freescale/fec.c
index 0704bca..6573bd5 100644
--- a/drivers/net/ethernet/freescale/fec.c
+++ b/drivers/net/ethernet/freescale/fec.c
@@ -1628,6 +1628,11 @@ fec_probe(struct platform_device *pdev)
goto failed_clk;
}
+ /* enet_out is optional, depends on board */
+ fep->clk_enet_out = devm_clk_get(&pdev->dev, "enet_out");
+ if (IS_ERR(fep->clk_enet_out))
+ fep->clk_enet_out = NULL;
+
#ifdef CONFIG_FEC_PTP
fep->clk_ptp = devm_clk_get(&pdev->dev, "ptp");
if (IS_ERR(fep->clk_ptp)) {
@@ -1638,6 +1643,7 @@ fec_probe(struct platform_device *pdev)
clk_prepare_enable(fep->clk_ahb);
clk_prepare_enable(fep->clk_ipg);
+ clk_prepare_enable(fep->clk_enet_out);
#ifdef CONFIG_FEC_PTP
clk_prepare_enable(fep->clk_ptp);
#endif
@@ -1679,6 +1685,7 @@ failed_register:
failed_mii_init:
failed_init:
failed_regulator:
+ clk_disable_unprepare(fep->clk_enet_out);
clk_disable_unprepare(fep->clk_ahb);
clk_disable_unprepare(fep->clk_ipg);
#ifdef CONFIG_FEC_PTP
@@ -1722,6 +1729,7 @@ fec_drv_remove(struct platform_device *pdev)
if (fep->ptp_clock)
ptp_clock_unregister(fep->ptp_clock);
#endif
+ clk_disable_unprepare(fep->clk_enet_out);
clk_disable_unprepare(fep->clk_ahb);
clk_disable_unprepare(fep->clk_ipg);
iounmap(fep->hwp);
@@ -1747,6 +1755,7 @@ fec_suspend(struct device *dev)
fec_stop(ndev);
netif_device_detach(ndev);
}
+ clk_disable_unprepare(fep->clk_enet_out);
clk_disable_unprepare(fep->clk_ahb);
clk_disable_unprepare(fep->clk_ipg);
@@ -1759,6 +1768,7 @@ fec_resume(struct device *dev)
struct net_device *ndev = dev_get_drvdata(dev);
struct fec_enet_private *fep = netdev_priv(ndev);
+ clk_prepare_enable(fep->clk_enet_out);
clk_prepare_enable(fep->clk_ahb);
clk_prepare_enable(fep->clk_ipg);
if (netif_running(ndev)) {
diff --git a/drivers/net/ethernet/freescale/fec.h b/drivers/net/ethernet/freescale/fec.h
index c5a3bc1..0648dbe 100644
--- a/drivers/net/ethernet/freescale/fec.h
+++ b/drivers/net/ethernet/freescale/fec.h
@@ -203,6 +203,7 @@ struct fec_enet_private {
struct clk *clk_ipg;
struct clk *clk_ahb;
+ struct clk *clk_enet_out;
#ifdef CONFIG_FEC_PTP
struct clk *clk_ptp;
#endif
--
1.7.10.4
^ permalink raw reply related
* [RFC 2/3] arm: mxs: add enet_out clock to devicetree
From: Wolfram Sang @ 2013-01-29 14:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359470773-14290-1-git-send-email-w.sang@pengutronix.de>
Put the clock to the devicetree, so the driver can take care of it
later. Then, we don't have to do the enabling as a workaround in board
init.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
---
arch/arm/boot/dts/imx28-apf28.dts | 3 +++
arch/arm/boot/dts/imx28-apx4devkit.dts | 3 +++
arch/arm/boot/dts/imx28-cfa10049.dts | 3 +++
arch/arm/boot/dts/imx28-evk.dts | 3 +++
arch/arm/boot/dts/imx28-sps1.dts | 3 +++
arch/arm/boot/dts/imx28-tx28.dts | 3 +++
6 files changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/imx28-apf28.dts b/arch/arm/boot/dts/imx28-apf28.dts
index 7eb0758..3047c0c 100644
--- a/arch/arm/boot/dts/imx28-apf28.dts
+++ b/arch/arm/boot/dts/imx28-apf28.dts
@@ -75,6 +75,9 @@
ahb at 80080000 {
mac0: ethernet at 800f0000 {
+ /* add enet_out clock */
+ clocks = <&clks 57>, <&clks 57>, <&clks 64>;
+ clock-names = "ipg", "ahb", "enet_out";
phy-mode = "rmii";
pinctrl-names = "default";
pinctrl-0 = <&mac0_pins_a>;
diff --git a/arch/arm/boot/dts/imx28-apx4devkit.dts b/arch/arm/boot/dts/imx28-apx4devkit.dts
index 5171667..b8c4b0c 100644
--- a/arch/arm/boot/dts/imx28-apx4devkit.dts
+++ b/arch/arm/boot/dts/imx28-apx4devkit.dts
@@ -159,6 +159,9 @@
ahb at 80080000 {
mac0: ethernet at 800f0000 {
+ /* add enet_out clock */
+ clocks = <&clks 57>, <&clks 57>, <&clks 64>;
+ clock-names = "ipg", "ahb", "enet_out";
phy-mode = "rmii";
pinctrl-names = "default";
pinctrl-0 = <&mac0_pins_a>;
diff --git a/arch/arm/boot/dts/imx28-cfa10049.dts b/arch/arm/boot/dts/imx28-cfa10049.dts
index bdc80a4..7204468 100644
--- a/arch/arm/boot/dts/imx28-cfa10049.dts
+++ b/arch/arm/boot/dts/imx28-cfa10049.dts
@@ -145,6 +145,9 @@
ahb at 80080000 {
mac0: ethernet at 800f0000 {
+ /* add enet_out clock */
+ clocks = <&clks 57>, <&clks 57>, <&clks 64>;
+ clock-names = "ipg", "ahb", "enet_out";
phy-mode = "rmii";
pinctrl-names = "default";
pinctrl-0 = <&mac0_pins_a>;
diff --git a/arch/arm/boot/dts/imx28-evk.dts b/arch/arm/boot/dts/imx28-evk.dts
index 2da316e..6634d71 100644
--- a/arch/arm/boot/dts/imx28-evk.dts
+++ b/arch/arm/boot/dts/imx28-evk.dts
@@ -224,6 +224,9 @@
};
mac0: ethernet at 800f0000 {
+ /* add enet_out clock */
+ clocks = <&clks 57>, <&clks 57>, <&clks 64>;
+ clock-names = "ipg", "ahb", "enet_out";
phy-mode = "rmii";
pinctrl-names = "default";
pinctrl-0 = <&mac0_pins_a>;
diff --git a/arch/arm/boot/dts/imx28-sps1.dts b/arch/arm/boot/dts/imx28-sps1.dts
index e6cde8a..1df1859 100644
--- a/arch/arm/boot/dts/imx28-sps1.dts
+++ b/arch/arm/boot/dts/imx28-sps1.dts
@@ -112,6 +112,9 @@
};
mac0: ethernet at 800f0000 {
+ /* add enet_out clock */
+ clocks = <&clks 57>, <&clks 57>, <&clks 64>;
+ clock-names = "ipg", "ahb", "enet_out";
phy-mode = "rmii";
pinctrl-names = "default";
pinctrl-0 = <&mac0_pins_a>;
diff --git a/arch/arm/boot/dts/imx28-tx28.dts b/arch/arm/boot/dts/imx28-tx28.dts
index 37be532..dcc90db 100644
--- a/arch/arm/boot/dts/imx28-tx28.dts
+++ b/arch/arm/boot/dts/imx28-tx28.dts
@@ -89,6 +89,9 @@
ahb at 80080000 {
mac0: ethernet at 800f0000 {
+ /* add enet_out clock */
+ clocks = <&clks 57>, <&clks 57>, <&clks 64>;
+ clock-names = "ipg", "ahb", "enet_out";
phy-mode = "rmii";
pinctrl-names = "default", "gpio_mode";
pinctrl-0 = <&mac0_pins_a>;
--
1.7.10.4
^ permalink raw reply related
* [RFC 3/3] arm: mach-mxs: make enabling enet_out a legacy function
From: Wolfram Sang @ 2013-01-29 14:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359470773-14290-1-git-send-email-w.sang@pengutronix.de>
enet_out is now handled via the driver, so handling it in board init
will print a warning.
Signed-off-by: Wolfram Sang <w.sang@pengutronix.de>
---
arch/arm/mach-mxs/mach-mxs.c | 24 ++++++++++++++++--------
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/arch/arm/mach-mxs/mach-mxs.c b/arch/arm/mach-mxs/mach-mxs.c
index c66129b..1f2e3bf 100644
--- a/arch/arm/mach-mxs/mach-mxs.c
+++ b/arch/arm/mach-mxs/mach-mxs.c
@@ -252,17 +252,25 @@ static void __init imx23_evk_init(void)
mxsfb_pdata.ld_intf_width = STMLCDIF_24BIT;
}
-static inline void enable_clk_enet_out(void)
+static inline void legacy_enable_clk_enet_out(void)
{
- struct clk *clk = clk_get_sys("enet_out", NULL);
+ struct device_node *np;
+ struct clk *clk;
+
+ for_each_compatible_node(np, NULL, "fsl,imx28-fec")
+ if (of_property_match_string(np, "clock-names", "enet_out") >= 0)
+ return;
+
+ WARN(1, "Please specify enet_out-clk in devicetree.\n");
+ clk = clk_get_sys("enet_out", NULL);
if (!IS_ERR(clk))
clk_prepare_enable(clk);
}
static void __init imx28_evk_init(void)
{
- enable_clk_enet_out();
+ legacy_enable_clk_enet_out();
update_fec_mac_prop(OUI_FSL);
mxsfb_pdata.mode_list = mx28evk_video_modes;
@@ -292,7 +300,7 @@ static void __init m28evk_init(void)
static void __init sc_sps1_init(void)
{
- enable_clk_enet_out();
+ legacy_enable_clk_enet_out();
}
static int apx4devkit_phy_fixup(struct phy_device *phy)
@@ -303,7 +311,7 @@ static int apx4devkit_phy_fixup(struct phy_device *phy)
static void __init apx4devkit_init(void)
{
- enable_clk_enet_out();
+ legacy_enable_clk_enet_out();
if (IS_BUILTIN(CONFIG_PHYLIB))
phy_register_fixup_for_uid(PHY_ID_KSZ8051, MICREL_PHY_ID_MASK,
@@ -351,7 +359,7 @@ static void __init tx28_post_init(void)
struct pinctrl *pctl;
int ret;
- enable_clk_enet_out();
+ legacy_enable_clk_enet_out();
np = of_find_compatible_node(NULL, NULL, "fsl,imx28-fec");
pdev = of_find_device_by_node(np);
@@ -391,13 +399,13 @@ static void __init tx28_post_init(void)
static void __init cfa10049_init(void)
{
- enable_clk_enet_out();
+ legacy_enable_clk_enet_out();
update_fec_mac_prop(OUI_CRYSTALFONTZ);
}
static void __init apf28_init(void)
{
- enable_clk_enet_out();
+ legacy_enable_clk_enet_out();
mxsfb_pdata.mode_list = apf28dev_video_modes;
mxsfb_pdata.mode_count = ARRAY_SIZE(apf28dev_video_modes);
--
1.7.10.4
^ permalink raw reply related
* [RFC] arm: use built-in byte swap function
From: Rob Herring @ 2013-01-29 14:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128193033.8a0b0a871150c99247f05a95@freescale.com>
On 01/28/2013 07:30 PM, Kim Phillips wrote:
> Enable the compiler intrinsic for byte swapping on arch ARM. This
> allows the compiler to detect and be able to optimize out byte
> swappings, e.g. in big endian to big endian moves.
>
> AFAICT, arm gcc got __builtin_bswap{32,64} support in 4.6,
> and for the 16-bit version in 4.8.
I think these are the versions ARM got optimized swap support. The newer
compilers are smart enough to replace a swap written in C with a rev
instruction. Last time I checked, they did not do rev16, but that is
probably what was added in 4.8 (and backported to Linaro gcc). The
Linaro backports make it impossible to define what gcc version has a
specific feature.
If you specify to use the builtin's, do you still get inline rev
instructions emitted?
Rob
>
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> ---
> akin to: http://comments.gmane.org/gmane.linux.kernel.cross-arch/16016
>
> based on linux-next. Depends on commit "compiler-gcc{3,4}.h: Use
> GCC_VERSION macro" by Daniel Santos <daniel.santos@pobox.com>,
> currently in the akpm branch.
>
> RFC because of unfamiliarity with arch ARM, and that at91sam9rl,
> at91rm9200, and lpd270 (so far, at least) builds fail with:
>
> include/uapi/linux/swab.h:60: undefined reference to `__bswapsi2'
>
> I'm using eldk-5.2.1/armv7a's arm-linux-gnueabi-gcc (GCC) 4.6.4
> 20120303 (prerelease)
>
> arch/arm/Kconfig | 1 +
> include/linux/compiler-gcc4.h | 3 ++-
> 2 files changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index eda8711..437d11a 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -3,6 +3,7 @@ config ARM
> default y
> select ARCH_BINFMT_ELF_RANDOMIZE_PIE
> select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
> + select ARCH_USE_BUILTIN_BSWAP
> select ARCH_HAVE_CUSTOM_GPIO_H
> select ARCH_WANT_IPC_PARSE_VERSION
> select BUILDTIME_EXTABLE_SORT if MMU
> diff --git a/include/linux/compiler-gcc4.h b/include/linux/compiler-gcc4.h
> index 68b162d..da5f728 100644
> --- a/include/linux/compiler-gcc4.h
> +++ b/include/linux/compiler-gcc4.h
> @@ -67,7 +67,8 @@
>
>
> #ifdef CONFIG_ARCH_USE_BUILTIN_BSWAP
> -#if GCC_VERSION >= 40400
> +#if (!defined(__arm__) && GCC_VERSION >= 40400) || \
> + (defined(__arm__) && GCC_VERSION >= 40600)
> #define __HAVE_BUILTIN_BSWAP32__
> #define __HAVE_BUILTIN_BSWAP64__
> #endif
>
^ permalink raw reply
* [PATCH,RFC] usb: add devicetree helpers for determining dr_mode and phy_type
From: Wolfram Sang @ 2013-01-29 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129143302.GF2046@arwen.pp.htv.fi>
> I prefer u32 here, because we have the matching enum. Otherwise we end
> up with:
>
> of_property_read_string(...,&type);
>
> if (!strcmp(type, "ulpi"))
> foo();
> else if (!strcmp(type, "utmi"))
> bar();
> else if (!strcmp(type, "pipe3"))
> baz();
> else
> BUG();
>
> and I don't like that, it's ugly and error prone.
Error prone? I guess my mileage varies. Especially compared to the
probability devicetree creators pick the wrong number.
It also removes the (probably implicit) rule that the enum mustn't be
modified since it is exported to users.
Also, you could map the strings to the enum first and then switch-case
over it to make the code nicer.
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130129/62825868/attachment.sig>
^ permalink raw reply
* [PATCH 1/5] dmaengine: dw_dmac: move to generic DMA binding
From: Arnd Bergmann @ 2013-01-29 14:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129142434.GW23505@n2100.arm.linux.org.uk>
On Tuesday 29 January 2013, Russell King - ARM Linux wrote:
> No, that's not what I mean. I mean the situation we find on Versatile
> platforms:
>
> 8 3 >3
> PL080 DMA --/--+--/------> FPGA Mux --/--> {bunch of off-CPU peripherals}
> | 5
> `--/------> {On-CPU peripherals}
>
> This is something that I've been raising _every time_ I've been involved
> with DMA engine discussions when it comes to the matching stuff, so this
> is nothing new, and it's not unknown about.
Ok, I see. I have not actually been involved with the DMA engine API
much, so for me it's the first time /I/ see this being explained.
>From the DT binding perspective, doing this should be no problem. I guess
you would model the MUX as a trivial dma engine device that forwards to
another one, just like we do for nested interrupt controllers:
pl080: dma-engine at 10000000 {
compatible ="arm,pl080", "arm,primecell";
reg = <0x10000000 0x1000>;
dma-requests = <8>;
dma-channels = <4>;
#dma-cells = <2>;
};
fpga {
mux: dma-mux at f0008000 {
reg = <0xf0008000 100>;
compatible = "arm,versatile-fpga-dmamux";
dma-requests = <7>;
dma-channels = <3>;
#dma-cells = <1>;
dmas = <&pl080 5 0>, <&pl080 6 0> <&pl080 7 0>;
dma-names = "mux5", "mux6", "mux7";
};
...
some-device at f000a000 {
compatible = "foo,using-muxed-dma";
dmas = <&mux 3>, <&mux 4>;
dma-names = "rx", "tx";
};
};
The driver for foo,using-muxed-dma just requests a slave channel for its
lines, which ends up calling the xlate function of the driver for the mux.
That driver still needs to get written, of course, but it should be able
to recursively call dma_request_slave_channel on the pl080 device.
The arm,versatile-fpga-dmamux driver would not be registered to the dmaengine
layer, but it would register as an of_dma_controller.
Arnd
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Thierry Reding @ 2013-01-29 15:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129152937.53ec9a9b@skate>
On Tue, Jan 29, 2013 at 03:29:37PM +0100, Thomas Petazzoni wrote:
> Dear Thierry Reding,
>
> On Tue, 29 Jan 2013 15:20:15 +0100, Thierry Reding wrote:
>
> > If at all possible I think the right thing to do is reuse the generic
> > pcibios_get_phb_of_node() implementation. On Tegra this turned out to
> > require a minimal change to the DT bindings of the root port nodes to
> > make sure they provide the correct address in the reg property.
>
> Could you detail the change that was needed? The DT bindings I use for
> the Marvell PCIe driver are very, very similar to the ones you use for
> Tegra, since I basically inspired my entire DT binding on your work.
> And still, I think of_irq_map_pci() wasn't working for me.
Now that I think about it, there were a few more changes needed.
For one, the reg property of the root port nodes need to be in the
format specified by the PCI DT binding. That is, 3 cells for the
address and 2 cells for the size.
So I end up with something like this:
pcie-controller {
...
ranges = <0x00000800 0 0x80000000 0x80000000 0 0x00001000 /* port 0 registers */
0x00001000 0 0x80001000 0x80001000 0 0x00001000 /* port 1 registers */
...>;
pci at 1,0 {
reg = <0x000800 0 0x80000000 0 0x1000>;
...
};
pci at 2,0 {
reg = <0x001000 0 0x80001000 0 0x1000>;
...
};
};
So what happens here is that for each root port (pci at 1,0 and pci at 2,0),
the reg property is translated into the parent address space via the
pcie-controller's ranges property. pci at 1,0 gets the memory region
0x80000000-0x80000fff and pci at 2,0 gets 0x80001000-0x80001fff. (These are
actually windows through which the configuration space of the root ports
is accessed.)
At the same time this reg property maps both devices into the PCI
address space at addresses 0:01.0 and 0:02.0 respectively.
The second change is that you can't rely on ARM's default implementation
of the bus scan operation, which calls pci_scan_root_bus(), passing in a
NULL as the struct device which acts as the bus' parent. So on Tegra I
added a custom implementation which calls pci_create_root_bus(), passing
in the struct device of the PCI host bridge, whose .of_node field will
be set to the pcie-controller node above. Incidentally this also fixed
another issue where the PCI core and ARM's pci_common_init() both
eventually end up calling pci_bus_add_devices(). I don't remember the
exact symptoms but I think this was causing resource conflicts during
the second enumeration or so.
Because a proper struct device with the correct .of_node field is passed
into pci_create_root_bus(), the generic pcibios_get_phb_of_node() will
know how to find it by looking at bus->bridge->parent->of_node. After
that the generic matching code will search the bridge (pcie-controller)
node's children and relate them to the struct pci_dev by devfn. This is
done in pci_set_of_node() defined in drivers/pci/of.c, which calls
of_pci_find_child_device() from drivers/of/of_pci.c.
This is quite convoluted, but I hope it helps.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130129/1a0b14a8/attachment.sig>
^ permalink raw reply
* [PATCH,RFC] usb: add devicetree helpers for determining dr_mode and phy_type
From: Marc Kleine-Budde @ 2013-01-29 15:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129145500.GB3323@pengutronix.de>
On 01/29/2013 03:55 PM, Wolfram Sang wrote:
>
>> I prefer u32 here, because we have the matching enum. Otherwise we end
>> up with:
>>
>> of_property_read_string(...,&type);
>>
>> if (!strcmp(type, "ulpi"))
>> foo();
>> else if (!strcmp(type, "utmi"))
>> bar();
>> else if (!strcmp(type, "pipe3"))
>> baz();
>> else
>> BUG();
>>
>> and I don't like that, it's ugly and error prone.
>
> Error prone? I guess my mileage varies. Especially compared to the
> probability devicetree creators pick the wrong number.
>
> It also removes the (probably implicit) rule that the enum mustn't be
> modified since it is exported to users.
>
> Also, you could map the strings to the enum first and then switch-case
> over it to make the code nicer.
That's what the code already does.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 263 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130129/f33d6864/attachment.sig>
^ permalink raw reply
* [PATCH v4] ARM: LPAE: Fix mapping in alloc_init_pte for unaligned addresses
From: R Sricharan @ 2013-01-29 15:07 UTC (permalink / raw)
To: linux-arm-kernel
With LPAE enabled, alloc_init_section() does not map the
entire address space for unaligned addresses.
The issue also reproduced with CMA + LPAE. CMA tries to map 16MB
with page granularity mappings during boot. alloc_init_pte()
is called and out of 16MB, only 2MB gets mapped and rest remains
unaccessible.
Because of this OMAP5 boot is broken with CMA + LPAE enabled.
Fix the issue by ensuring that the entire addresses are
mapped.
Signed-off-by: R Sricharan <r.sricharan@ti.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Christoffer Dall <chris@cloudcar.com>
Cc: Russell King <linux@arm.linux.org.uk>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Tested-by: Christoffer Dall <chris@cloudcar.com>
---
[V2] Moved the loop to alloc_init_pte as per Russell's
feedback and changed the subject accordingly.
Using PMD_XXX instead of SECTION_XXX to avoid
different loop increments with/without LPAE.
[v3] Removed the dummy variable phys and updated
the commit log for CMA case.
[v4] Resending with updated change log and
updating the tags.
arch/arm/mm/mmu.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index f8388ad..b94c313 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -569,11 +569,23 @@ static void __init alloc_init_pte(pmd_t *pmd, unsigned long addr,
unsigned long end, unsigned long pfn,
const struct mem_type *type)
{
- pte_t *pte = early_pte_alloc(pmd, addr, type->prot_l1);
+ unsigned long next;
+ pte_t *pte;
+
do {
- set_pte_ext(pte, pfn_pte(pfn, __pgprot(type->prot_pte)), 0);
- pfn++;
- } while (pte++, addr += PAGE_SIZE, addr != end);
+ if ((end-addr) & PMD_MASK)
+ next = (addr + PMD_SIZE) & PMD_MASK;
+ else
+ next = end;
+
+ pte = early_pte_alloc(pmd, addr, type->prot_l1);
+ do {
+ set_pte_ext(pte, pfn_pte(pfn,
+ __pgprot(type->prot_pte)), 0);
+ pfn++;
+ } while (pte++, addr += PAGE_SIZE, addr != next);
+
+ } while (pmd++, addr = next, addr != end);
}
static void __init alloc_init_section(pud_t *pud, unsigned long addr,
--
1.7.9.5
^ permalink raw reply related
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Andrew Murray @ 2013-01-29 15:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129150201.GA24101@avionic-0098.mockup.avionic-design.de>
On Tue, Jan 29, 2013 at 03:02:01PM +0000, Thierry Reding wrote:
> On Tue, Jan 29, 2013 at 03:29:37PM +0100, Thomas Petazzoni wrote:
> > Dear Thierry Reding,
> >
> > On Tue, 29 Jan 2013 15:20:15 +0100, Thierry Reding wrote:
> >
> > > If at all possible I think the right thing to do is reuse the generic
> > > pcibios_get_phb_of_node() implementation. On Tegra this turned out to
> > > require a minimal change to the DT bindings of the root port nodes to
> > > make sure they provide the correct address in the reg property.
> >
> > Could you detail the change that was needed? The DT bindings I use for
> > the Marvell PCIe driver are very, very similar to the ones you use for
> > Tegra, since I basically inspired my entire DT binding on your work.
> > And still, I think of_irq_map_pci() wasn't working for me.
>
> Now that I think about it, there were a few more changes needed.
> For one, the reg property of the root port nodes need to be in the
> format specified by the PCI DT binding. That is, 3 cells for the
> address and 2 cells for the size.
>
> So I end up with something like this:
>
> pcie-controller {
> ...
>
> ranges = <0x00000800 0 0x80000000 0x80000000 0 0x00001000 /* port 0 registers */
> 0x00001000 0 0x80001000 0x80001000 0 0x00001000 /* port 1 registers */
> ...>;
>
> pci at 1,0 {
> reg = <0x000800 0 0x80000000 0 0x1000>;
> ...
> };
>
> pci at 2,0 {
> reg = <0x001000 0 0x80001000 0 0x1000>;
> ...
> };
> };
>
> So what happens here is that for each root port (pci at 1,0 and pci at 2,0),
> the reg property is translated into the parent address space via the
> pcie-controller's ranges property. pci at 1,0 gets the memory region
> 0x80000000-0x80000fff and pci at 2,0 gets 0x80001000-0x80001fff. (These are
> actually windows through which the configuration space of the root ports
> is accessed.)
>
> At the same time this reg property maps both devices into the PCI
> address space at addresses 0:01.0 and 0:02.0 respectively.
>
> The second change is that you can't rely on ARM's default implementation
> of the bus scan operation, which calls pci_scan_root_bus(), passing in a
> NULL as the struct device which acts as the bus' parent. So on Tegra I
> added a custom implementation which calls pci_create_root_bus(), passing
> in the struct device of the PCI host bridge, whose .of_node field will
> be set to the pcie-controller node above. Incidentally this also fixed
> another issue where the PCI core and ARM's pci_common_init() both
> eventually end up calling pci_bus_add_devices(). I don't remember the
> exact symptoms but I think this was causing resource conflicts during
> the second enumeration or so.
>
> Because a proper struct device with the correct .of_node field is passed
> into pci_create_root_bus(), the generic pcibios_get_phb_of_node() will
> know how to find it by looking at bus->bridge->parent->of_node. After
> that the generic matching code will search the bridge (pcie-controller)
> node's children and relate them to the struct pci_dev by devfn. This is
> done in pci_set_of_node() defined in drivers/pci/of.c, which calls
> of_pci_find_child_device() from drivers/of/of_pci.c.
>
> This is quite convoluted, but I hope it helps.
Thanks this is very helpful. I will see if this lets me avoid implementing
pcibios_get_phb_of_node.
Thanks,
Andrew Murray
^ permalink raw reply
* [GIT PULL] imx cleanup for 3.9
From: Shawn Guo @ 2013-01-29 15:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130129141857.GA12723@quad.lixom.net>
On Tue, Jan 29, 2013 at 06:18:57AM -0800, Olof Johansson wrote:
> Ok. Just to make clear: While I personally prefer the regular way of specifying
> the board dts files, my main concern with this patch is that it is _pure
> churn_. It's 1000 lines of change without a functional benefit, and without
> really being a cleanup that benefits long-term development.
>
You can say it's not a cleanup, but it definitely benefits long-term
development. It makes board dts development a lot easier, and that's
why I came up with the patch.
> We're starting to get more comments about the volume of churn again (Linus made
> a couple of them the last merge window), and I'd rather be a bit more
> conservative on some of the larger changes that lack strong benefit for
> a release or two, than have him get ticked off and make life miserable for all
> of us.
>
> So, I'm not saying that it's a bad idea to change to labels, but I would rather
> hold off this while we give some of the remaining platforms still not
> multiplatform-enabled a chance to "use the churn quota" since they will need it
> for include file moves, etc, etc.
>
Then it will hold off the while IMX device tree development. All the
patches I queued on imx/dt branch are all based on that. While it
looks like a "churn", it should not cause any conflict, as all IMX
dts changes will go via the same branch for this cycle. So please
give it a go to avoid hurting people who contribute IMX device tree
development.
Shawn
^ 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