* OMAP baseline test results for v3.8-rc4
From: Bedia, Vaibhav @ 2013-01-24 12:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1301220213390.25789@utopia.booyaka.com>
Hi Paul,
On Tue, Jan 22, 2013 at 07:54:44, Paul Walmsley wrote:
>
> Hi guys,
>
> Regarding the AM33xx test failures with appended DTBs, it would be very
> helpful if especially the TI people could try reproducing the problem.
> Otherwise it's going to cause problems with merging any new AM33xx
> patches, since I won't be able to test them without additional work.
> Plus, this is something that used to work up until d01e4afd, so something
> isn't right.
>
> You'll need to use the bootloader that TI originally shipped with the
> BeagleBones:
>
> U-Boot 2011.09-00009-gcf6e04d (Mar 08 2012 - 17:15:43)
>
> This is because many folks don't replace their bootloader. I do plan to
> add a test with a recent version of u-boot, but the kernel should not be
> dependent on the bootloader in any way to work correctly. If it is, then
> we need to document what u-boot version the kernel started to work with.
>
> The Kconfig that I use is here:
>
> http://www.pwsan.com/omap/testlogs/test_v3.8-rc4/20130120122039/build/am33xx_only/am33xx_only
>
> It's possible that there's something wrong with the Kconfig. It's
> basically just omap2plus_defconfig, but with all OMAP support for
> non-AM33xx turned off, and with the appended DTB and ATAG compatibility
> options turned on.
>
> Let's try to do this ASAP. That way, if it's some bootloader dependency
> or bug in the kernel, some fix can be merged during the v3.8-rc series,
> which is rapidly drawing to a close.
>
I could not track down U-Boot that you were using so I used the v2013.01 tag
for U-Boot. However, using your build configs for v3.7 and v3.8-rcX I got the same
observations i.e. v3.7 boots but others don't.
One difference that I found was that post v3.7 the configs that you are using have
CONFIG_EARLY_PRINTK set. Once I disabled that I was able to bootup v3.8-rc1/4
(didn't try rc2/3 but I suspect early_printk was the culprit there too).
I checked with Santosh on this and he mentioned that for DT-only boot, which AM335x is,
that's expected behavior.
Can you update your AM335x-only config to disable CONFIG_EARLY_PRINTK or just skip
earlyprintk option in the bootargs for now?
If you still have issues booting can you update your U-Boot to v2013.01 since things
seem to be working fine at this point.
Regards,
Vaibhav
^ permalink raw reply
* [PATCH] ARM: dts: specify all the per-cpu interrupts of arch timer for exynos5440
From: Santosh Shilimkar @ 2013-01-24 12:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51012C4B.5080300@ti.com>
On Thursday 24 January 2013 06:12 PM, Benoit Cousson wrote:
> Hi Santosh,
>
> On 01/23/2013 11:55 AM, Santosh Shilimkar wrote:
>> Looping Marc, Benoit
>>
>> On Wednesday 23 January 2013 04:06 PM, Mark Rutland wrote:
>>> On Tue, Jan 22, 2013 at 10:05:18PM +0000, Kukjin Kim wrote:
>>>> Mark Rutland wrote:
>>>>>
>>>> + devicetree-discuss, Grant Likely, Rob Herring and Tony Lindgren
>>>>
>>>>> On Tue, Jan 22, 2013 at 01:41:27AM +0000, Kukjin Kim wrote:
>>>>>> From: Thomas Abraham <thomas.ab@samsung.com>
>>>>>>
>>>>>> Need to be changed requirements in the 'cpus' node for exynos5440
>>>>>> to specify all the per-cpu interrupts of arch timer.
>>>>>
>>>>> The node(s) for the arch timer should not be in the cpus/cpu at N nodes.
>>>>> Instead, there should be one node (in the root of the tree).
>>>>>
>>>> Well, I don't think so. As per my understanding, the local timers are
>>>> attached to every ARM cores (cpus) and it generates certain interrupt
>>>> to the
>>>> GIC. So the correct representation for this in device tree is to
>>>> include the
>>>> interrupts in the cpu nodes in dts file. Your comments refer to a
>>>> limitation in the Linux kernel implementation of the arch_timer and it
>>>> should not result in representing the hardware details incorrectly in
>>>> the
>>>> dts file.
>>>
>>> I disagree. The "correct representation" is whatever the devicetree
>>> binding
>>> documentation describes. It does not describe placing timer nodes in
>>> the cpu
>>> nodes.
>>>
>> This seems to be exact same topic what is getting discussed here [1]
>> Technically DT is suppose to represent how the hardware is rather than
>> how the bindings are done.
>>
>> But as Marc pointed out, the approach taken currently is to not
>> duplicate the banked information. The thread [1] isn't concluded
>> yet but looks like we might want to avoid duplicating the information
>> considering, more of such duplication needs to follow. e.g gic i/f
>>
>> Am still waiting on what Benoit has to say ?
>
> I agree with you :-)
>
> I'm not sure the binding was properly done to reflect the HW accurately.
>
> A local timer for my point of view should be located in the cpu node
> like a L1 cache. Or at least referenced in each cpu by a phandle.
>
> What was the rational to put it in the root?
>
From Marc's answer it seems to avoid the duplication of data but
I let him elaborate it.
Regards,
Santosh
^ permalink raw reply
* [PATCH V2 2/2] mmc: mmci: Move ios_handler functionality into the driver
From: Ulf Hansson @ 2013-01-24 12:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130123111805.GI15873@gmail.com>
On 23 January 2013 12:18, Lee Jones <lee.jones@linaro.org> wrote:
> On Wed, 23 Jan 2013, Russell King - ARM Linux wrote:
>
>> On Wed, Jan 23, 2013 at 10:13:49AM +0000, Lee Jones wrote:
>> > On Tue, 22 Jan 2013, Lee Jones wrote:
>> > > Are you saying that you won't do it? :)
>> > >
>> > > Is there anything I can do to make the process easier?
>> >
>> > Thinking about this a little more. Is it easier to remove it from your
>> > tree altogether? Only I have a small "ARM: ux500: " patch-set which
>> > directly relies on this patch. I could take it in via ARM-SoC without
>> > any fear of ordering issues.
>>
>> Thankfully, the patch doesn't conflict with any of the others I have, so
>> we can do that (and it's actually easier to do that.)
>>
>> Done.
>
> Brilliant, that's 2 birds with one stone. I'll queue it up for ARM-SoC.
>
> Thanks Russell.
>
> --
> Lee Jones
> Linaro ST-Ericsson Landing Team Lead
> Linaro.org ? Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
As long as it goes in for 3.9 I am happy. I am also depending on this
to add the UHS support for SD-cards for mmci. :-)
Kind regards
Ulf Hansson
^ permalink raw reply
* [PATCH 3/4] drm/tilcdc: add encoder slave
From: Daniel Vetter @ 2013-01-24 13:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358894185-21617-4-git-send-email-robdclark@gmail.com>
On Tue, Jan 22, 2013 at 04:36:24PM -0600, Rob Clark wrote:
> Add output panel driver for i2c encoder slaves.
>
> Signed-off-by: Rob Clark <robdclark@gmail.com>
Found some more stuff ...
[cut]
> +static const struct drm_encoder_helper_funcs slave_encoder_helper_funcs = {
> + .dpms = drm_i2c_encoder_dpms,
> + .mode_fixup = drm_i2c_encoder_mode_fixup,
> + .prepare = slave_encoder_prepare,
> + .commit = drm_i2c_encoder_commit,
> + .mode_set = drm_i2c_encoder_mode_set,
> + .save = drm_i2c_encoder_save,
> + .restore = drm_i2c_encoder_restore,
> +};
I couldn't find these wrappers anywhere ...
> +
> +static const struct i2c_board_info info = {
> + I2C_BOARD_INFO("tda998x", 0x70)
> +};
Shouldn't there be some of/devicetree thing to tell us which one to load?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* [PATCH 4/4] drm/tilcdc: add support for LCD panels (v4)
From: Daniel Vetter @ 2013-01-24 13:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358894185-21617-5-git-send-email-robdclark@gmail.com>
On Tue, Jan 22, 2013 at 04:36:25PM -0600, Rob Clark wrote:
> Add an output panel driver for LCD panels. Tested with LCD3 cape on
> beaglebone.
>
> v1: original
> v2: s/of_find_node_by_name()/of_get_child_by_name()/ from Pantelis
> Antoniou
> v3: add backlight support
> v4: rebase to latest of video timing helpers
>
> Signed-off-by: Rob Clark <robdclark@gmail.com>
So given that I'm utterly lacking clue about all things of (which seems to
be where all the magic in this patch lies) I'm just gonna ask a few funny
questions.
[cut]
> +static int panel_connector_get_modes(struct drm_connector *connector)
> +{
> + struct drm_device *dev = connector->dev;
> + struct panel_connector *panel_connector = to_panel_connector(connector);
> + struct display_timings *timings = panel_connector->mod->timings;
> + int i;
> +
> + for (i = 0; i < timings->num_timings; i++) {
> + struct drm_display_mode *mode = drm_mode_create(dev);
> + struct videomode vm;
> +
> + if (videomode_from_timing(timings, &vm, i))
> + break;
> +
> + drm_display_mode_from_videomode(&vm, mode);
Why do we need to jump through the intermediate videomode thing here? Is
that a deficiency of the of/videomode stuff?
[cut]
> + ret |= of_property_read_u32(info_np, "ac-bias", &info->ac_bias);
> + ret |= of_property_read_u32(info_np, "ac-bias-intrpt", &info->ac_bias_intrpt);
> + ret |= of_property_read_u32(info_np, "dma-burst-sz", &info->dma_burst_sz);
> + ret |= of_property_read_u32(info_np, "bpp", &info->bpp);
> + ret |= of_property_read_u32(info_np, "fdd", &info->fdd);
> + ret |= of_property_read_u32(info_np, "sync-edge", &info->sync_edge);
> + ret |= of_property_read_u32(info_np, "sync-ctrl", &info->sync_ctrl);
> + ret |= of_property_read_u32(info_np, "raster-order", &info->raster_order);
> + ret |= of_property_read_u32(info_np, "fifo-th", &info->fifo_th);
Shouldn't these values all be documented somewhere in the devictree docs?
Or are they somewhat standardized?
> +
> + /* optional: */
> + info->tft_alt_mode = of_property_read_bool(info_np, "tft-alt-mode");
> + info->stn_565_mode = of_property_read_bool(info_np, "stn-565-mode");
> + info->mono_8bit_mode = of_property_read_bool(info_np, "mono-8bit-mode");
> + info->invert_pxl_clk = of_property_read_bool(info_np, "invert-pxl-clk");
> +
> + if (of_property_read_u32(info_np, "max-bpp", &info->max_bpp))
> + info->max_bpp = info->bpp;
> + if (of_property_read_u32(info_np, "min-bpp", &info->min_bpp))
> + info->min_bpp = info->bpp;
> +
> + if (ret) {
> + pr_err("%s: error reading panel-info properties\n", __func__);
> + kfree(info);
> + return NULL;
> + }
> +
> + return info;
> +}
> +
> +static struct of_device_id panel_of_match[];
> +
> +static int panel_probe(struct platform_device *pdev)
> +{
> + struct device_node *node = pdev->dev.of_node;
> + struct panel_module *panel_mod;
> + struct tilcdc_module *mod;
> + struct pinctrl *pinctrl;
> + int ret = -EINVAL;
> +
> +
> + /* bail out early if no DT data: */
> + if (!node) {
> + dev_err(&pdev->dev, "device-tree data is missing\n");
> + return -ENXIO;
> + }
> +
> + panel_mod = kzalloc(sizeof(*panel_mod), GFP_KERNEL);
> + if (!panel_mod)
> + return -ENOMEM;
> +
> + mod = &panel_mod->base;
> +
> + tilcdc_module_init(mod, "panel", &panel_module_ops);
> +
> + pinctrl = devm_pinctrl_get_select_default(&pdev->dev);
> + if (IS_ERR(pinctrl))
> + dev_warn(&pdev->dev, "pins are not configured\n");
> +
> +
> + panel_mod->timings = of_get_display_timings(node);
> + if (!panel_mod->timings) {
> + dev_err(&pdev->dev, "could not get panel timings\n");
> + goto fail;
> + }
> +
> + panel_mod->info = of_get_panel_info(node);
> + if (!panel_mod->info) {
> + dev_err(&pdev->dev, "could not get panel info\n");
> + goto fail;
> + }
> +
> + panel_mod->backlight = of_find_backlight_by_node(node);
If this _really_ works that easily, I'll have of-envy for the rest of my
life :(
/me hates the real-world abomination called Intel backlight handling
Cheers, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* [PATCH v2 1/1 net-next] net: fec: add napi support to improve proformance
From: Florian Fainelli @ 2013-01-24 13:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359014309-8636-1-git-send-email-Frank.Li@freescale.com>
On 01/24/2013 08:58 AM, Frank Li wrote:
65,6 +566,20 @@ fec_timeout(struct net_device *ndev)
> }
>
> static void
> +fec_enet_rx_int_is_enabled(struct net_device *ndev, bool enabled)
> +{
> + struct fec_enet_private *fep = netdev_priv(ndev);
> + uint int_events;
> +
> + int_events = readl(fep->hwp + FEC_IMASK);
> + if (enabled)
> + int_events |= FEC_ENET_RXF;
> + else
> + int_events &= ~FEC_ENET_RXF;
> + writel(int_events, fep->hwp + FEC_IMASK);
> +}
This function is badly named with respect to what it does. A better name
would be fec_enet_rx_interrupt_set() for instance.
--
Florian
^ permalink raw reply
* [PATCH] ARM: dts: specify all the per-cpu interrupts of arch timer for exynos5440
From: Marc Zyngier @ 2013-01-24 13:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51012C4B.5080300@ti.com>
Hi Benoit,
On 24/01/13 12:42, Benoit Cousson wrote:
> Hi Santosh,
>
> On 01/23/2013 11:55 AM, Santosh Shilimkar wrote:
>> Looping Marc, Benoit
>>
>> On Wednesday 23 January 2013 04:06 PM, Mark Rutland wrote:
>>> On Tue, Jan 22, 2013 at 10:05:18PM +0000, Kukjin Kim wrote:
>>>> Mark Rutland wrote:
>>>>>
>>>> + devicetree-discuss, Grant Likely, Rob Herring and Tony Lindgren
>>>>
>>>>> On Tue, Jan 22, 2013 at 01:41:27AM +0000, Kukjin Kim wrote:
>>>>>> From: Thomas Abraham <thomas.ab@samsung.com>
>>>>>>
>>>>>> Need to be changed requirements in the 'cpus' node for exynos5440
>>>>>> to specify all the per-cpu interrupts of arch timer.
>>>>>
>>>>> The node(s) for the arch timer should not be in the cpus/cpu at N nodes.
>>>>> Instead, there should be one node (in the root of the tree).
>>>>>
>>>> Well, I don't think so. As per my understanding, the local timers are
>>>> attached to every ARM cores (cpus) and it generates certain interrupt
>>>> to the
>>>> GIC. So the correct representation for this in device tree is to
>>>> include the
>>>> interrupts in the cpu nodes in dts file. Your comments refer to a
>>>> limitation in the Linux kernel implementation of the arch_timer and it
>>>> should not result in representing the hardware details incorrectly in
>>>> the
>>>> dts file.
>>>
>>> I disagree. The "correct representation" is whatever the devicetree
>>> binding
>>> documentation describes. It does not describe placing timer nodes in
>>> the cpu
>>> nodes.
>>>
>> This seems to be exact same topic what is getting discussed here [1]
>> Technically DT is suppose to represent how the hardware is rather than
>> how the bindings are done.
>>
>> But as Marc pointed out, the approach taken currently is to not
>> duplicate the banked information. The thread [1] isn't concluded
>> yet but looks like we might want to avoid duplicating the information
>> considering, more of such duplication needs to follow. e.g gic i/f
>>
>> Am still waiting on what Benoit has to say ?
>
> I agree with you :-)
>
> I'm not sure the binding was properly done to reflect the HW accurately.
>
> A local timer for my point of view should be located in the cpu node
> like a L1 cache. Or at least referenced in each cpu by a phandle.
>
> What was the rational to put it in the root?
The rational was to follow what we already do for most (all?) banked
resources. We already have TWD, GIC and PMU that have a root node,
avoiding duplicated resources. I think consistency is an important thing
to have.
If we decide to move everything into CPU nodes and duplicate all the
banked resources, fine. But that has impacts that reach far beyond the
simple case of the timer.
In particular, good luck with the GIC distributor interface, where the
32 first interrupts are per CPU. This would also mandate a redesign of
the way we specify a PPI, as the CPU mask in the third field doesn't
mean a thing anymore.
If you insist on having a phandle to a timer node, fine by me.
Cheers,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH 1/2] ARM: dma-mapping: Add macro to_dma_iommu_mapping()
From: Hiroshi Doyu @ 2013-01-24 13:16 UTC (permalink / raw)
To: linux-arm-kernel
This can be built without CONFIG_ARM_DMA_USE_IOMMU.
Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com>
---
arch/arm/include/asm/device.h | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm/include/asm/device.h b/arch/arm/include/asm/device.h
index 5191a83..6fbe514 100644
--- a/arch/arm/include/asm/device.h
+++ b/arch/arm/include/asm/device.h
@@ -33,4 +33,10 @@ struct pdev_archdata {
#endif
};
+#ifdef CONFIG_ARM_DMA_USE_IOMMU
+#define to_dma_iommu_mapping(dev) ((dev)->archdata.mapping)
+#else
+#define to_dma_iommu_mapping(dev) NULL
+#endif
+
#endif
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/2] ARM: dma-mapping: Add arm_iommu_detach_device()
From: Hiroshi Doyu @ 2013-01-24 13:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359033425-6674-1-git-send-email-hdoyu@nvidia.com>
A counter part of arm_iommu_attach_device().
Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com>
---
arch/arm/include/asm/dma-iommu.h | 1 +
arch/arm/mm/dma-mapping.c | 25 +++++++++++++++++++++++++
2 files changed, 26 insertions(+)
diff --git a/arch/arm/include/asm/dma-iommu.h b/arch/arm/include/asm/dma-iommu.h
index 799b094..af1ac4ed 100644
--- a/arch/arm/include/asm/dma-iommu.h
+++ b/arch/arm/include/asm/dma-iommu.h
@@ -29,6 +29,7 @@ void arm_iommu_release_mapping(struct dma_iommu_mapping *mapping);
int arm_iommu_attach_device(struct device *dev,
struct dma_iommu_mapping *mapping);
+void arm_iommu_detach_device(struct device *dev);
#endif /* __KERNEL__ */
#endif
diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 6b2fb87..b075a1f 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1842,4 +1842,29 @@ int arm_iommu_attach_device(struct device *dev,
return 0;
}
+/**
+ * arm_iommu_detach_device
+ * @dev: valid struct device pointer
+ *
+ * Detaches the provided device from a previously attached map.
+ * This voids the dma operations (dma_map_ops pointer)
+ */
+void arm_iommu_detach_device(struct device *dev)
+{
+ struct dma_iommu_mapping *mapping;
+
+ mapping = to_dma_iommu_mapping(dev);
+ if (!mapping) {
+ dev_warn(dev, "Not attached\n");
+ return;
+ }
+
+ iommu_detach_device(mapping->domain, dev);
+ kref_put(&mapping->kref, release_iommu_mapping);
+ mapping = NULL;
+ set_dma_ops(dev, NULL);
+
+ pr_debug("Detached IOMMU controller from %s device.\n", dev_name(dev));
+}
+
#endif
--
1.7.9.5
^ permalink raw reply related
* [PATCH] i2c: samsung: resume race fix
From: Wolfram Sang @ 2013-01-24 13:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121107114437.0a563c7e@endymion.delvare>
On Wed, Nov 07, 2012 at 11:44:37AM +0100, Jean Delvare wrote:
> On Wed, 07 Nov 2012 15:58:26 +0530, Naveen Krishna Chatradhi wrote:
> > Don't unmark the device as suspended until after it's been re-setup.
> >
> > The main race would be w.r.t. an i2c driver that gets resumed at the same
> > time (asyncronously), that is allowed to do a transfer since suspended
> > is set to 0 before reinit, but really should have seen the -EIO return
> > instead.
>
> I thought that the suspend order was children first and the resume
> order was parent first?
Same here, why does it not work this way?
Regards,
Wolfram
--
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/20130124/818565c5/attachment-0001.sig>
^ permalink raw reply
* [RFC PATCH 6/6] ARM: kirkwood: consolidate mv643xx_eth init for DT
From: Florian Fainelli @ 2013-01-24 13:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <ecb64cdf824399badaf9d659177811d8cb091156.1358983578.git.jason@lakedaemon.net>
Hello Jason,
On 01/24/2013 12:34 AM, Jason Cooper wrote:
> replace a lot of unneeded code and files with a lookup table.
Would not it be better to keep all of this as-is and merge/improve Ian's
mv643xx_eth device tree bindings [1], and then only remove these files?
It is just 81 new lines, so it is not a big deal, just wondering here
what is best.
[1]: http://patchwork.ozlabs.org/patch/175652/
>
> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
--
Florian
^ permalink raw reply
* [RFC PATCH 3/6] ARM: kirkwood: nsa310: cleanup includes and unneeded code
From: Florian Fainelli @ 2013-01-24 13:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130124055052.GA21297@lunn.ch>
On 01/24/2013 06:50 AM, Andrew Lunn wrote:
> On Wed, Jan 23, 2013 at 11:34:21PM +0000, Jason Cooper wrote:
>> Signed-off-by: Jason Cooper <jason@lakedaemon.net>
>> ---
>> arch/arm/mach-kirkwood/board-nsa310.c | 9 +--------
>> 1 file changed, 1 insertion(+), 8 deletions(-)
>>
>> diff --git a/arch/arm/mach-kirkwood/board-nsa310.c b/arch/arm/mach-kirkwood/board-nsa310.c
>> index 1bd328d..0b99533 100644
>> --- a/arch/arm/mach-kirkwood/board-nsa310.c
>> +++ b/arch/arm/mach-kirkwood/board-nsa310.c
>> @@ -10,11 +10,8 @@
>>
>> #include <linux/kernel.h>
>> #include <linux/init.h>
>> -#include <linux/i2c.h>
>> -
>> -#include <asm/mach-types.h>
>> -#include <asm/mach/arch.h>
>> #include <mach/kirkwood.h>
>> +#include <linux/of.h>
>> #include "common.h"
>> #include "mpp.h"
>>
>> @@ -40,11 +37,7 @@ static unsigned int nsa310_mpp_config[] __initdata = {
>>
>> void __init nsa310_init(void)
>> {
>> - u32 dev, rev;
>> -
>> kirkwood_mpp_conf(nsa310_mpp_config);
>> -
>> - kirkwood_pcie_id(&dev, &rev);
>> }
>>
>> static int __init nsa310_pci_init(void)
>> --
>> 1.8.1.1
>>
>
> Hi Jason, Tero
>
> This board is rather unusual for a Kirkwood. It has no Ethernet
> interfaces. Is this correct?
It seems like it really has an Gigabit Ethernet interface:
http://www.clubic.com/disque-dur-memoire/nas/article-465814-1-zyxel-nsa-310.html
(in french, but the pictures show a Gigabit Ethernet).
--
Florian
^ permalink raw reply
* [PATCH v2 1/1 net-next] net: fec: add napi support to improve proformance
From: Eric Dumazet @ 2013-01-24 13:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359014309-8636-1-git-send-email-Frank.Li@freescale.com>
On Thu, 2013-01-24 at 15:58 +0800, Frank Li wrote:
>
> static irqreturn_t
> @@ -805,6 +823,7 @@ fec_enet_interrupt(int irq, void *dev_id)
> struct net_device *ndev = dev_id;
> struct fec_enet_private *fep = netdev_priv(ndev);
> uint int_events;
> + ulong flags;
> irqreturn_t ret = IRQ_NONE;
>
> do {
> @@ -813,7 +832,14 @@ fec_enet_interrupt(int irq, void *dev_id)
>
> if (int_events & FEC_ENET_RXF) {
> ret = IRQ_HANDLED;
> - fec_enet_rx(ndev);
> +
> + spin_lock_irqsave(&fep->hw_lock, flags);
You already are in a irq safe context, spin_lock() should be ok
> + /* Disable the RX interrupt */
> + if (napi_schedule_prep(&fep->napi)) {
> + fec_enet_rx_int_is_enabled(ndev, false);
> + __napi_schedule(&fep->napi);
> + }
> + spin_unlock_irqrestore(&fep->hw_lock, flags);
spin_unlock();
> }
>
Same remark for the spin_lock_irqsave(&fep->tmreg_lock, flags) in
fec_enet_tx()
^ permalink raw reply
* [RESEND PATCH v5 3/7] usb: chipidea: add otg id switch and vbus connect/disconnect detect
From: Alexander Shishkin @ 2013-01-24 14:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358733418-17969-4-git-send-email-peter.chen@freescale.com>
Peter Chen <peter.chen@freescale.com> writes:
> The main design flow is the same with msm otg driver, that is the id and
> vbus interrupt are handled at core driver, others are handled by
> individual drivers.
>
> - At former design, when switch usb role from device->host, it will call
> udc_stop, it will remove the gadget driver, so when switch role
> from host->device, it can't add gadget driver any more.
> At new design, when role switch occurs, the gadget just calls
> usb_gadget_vbus_disconnect/usb_gadget_vbus_connect as well as
> reset controller, it will not free any device/gadget structure
>
> - Add vbus connect and disconnect to core interrupt handler, it can
> notify udc driver by calling usb_gadget_vbus_disconnect
> /usb_gadget_vbus_connect.
>
> Signed-off-by: Peter Chen <peter.chen@freescale.com>
A few comments below.
> ---
> drivers/usb/chipidea/bits.h | 10 +++
> drivers/usb/chipidea/ci.h | 8 ++-
> drivers/usb/chipidea/core.c | 177 ++++++++++++++++++++++++++++++++++++++----
> drivers/usb/chipidea/otg.c | 28 +++++---
> drivers/usb/chipidea/otg.h | 3 +
> drivers/usb/chipidea/udc.c | 2 +
> 6 files changed, 200 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/usb/chipidea/bits.h b/drivers/usb/chipidea/bits.h
> index 050de85..ba9c6ef 100644
> --- a/drivers/usb/chipidea/bits.h
> +++ b/drivers/usb/chipidea/bits.h
> @@ -65,11 +65,21 @@
> #define OTGSC_ASVIS BIT(18)
> #define OTGSC_BSVIS BIT(19)
> #define OTGSC_BSEIS BIT(20)
> +#define OTGSC_1MSIS BIT(21)
> +#define OTGSC_DPIS BIT(22)
> #define OTGSC_IDIE BIT(24)
> #define OTGSC_AVVIE BIT(25)
> #define OTGSC_ASVIE BIT(26)
> #define OTGSC_BSVIE BIT(27)
> #define OTGSC_BSEIE BIT(28)
> +#define OTGSC_1MSIE BIT(29)
> +#define OTGSC_DPIE BIT(30)
> +#define OTGSC_INT_EN_BITS (OTGSC_IDIE | OTGSC_AVVIE | OTGSC_ASVIE \
> + | OTGSC_BSVIE | OTGSC_BSEIE | OTGSC_1MSIE \
> + | OTGSC_DPIE)
> +#define OTGSC_INT_STATUS_BITS (OTGSC_IDIS | OTGSC_AVVIS | OTGSC_ASVIS \
> + | OTGSC_BSVIS | OTGSC_BSEIS | OTGSC_1MSIS \
> + | OTGSC_DPIS)
>
> /* USBMODE */
> #define USBMODE_CM (0x03UL << 0)
> diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
> index 8702871..325d790 100644
> --- a/drivers/usb/chipidea/ci.h
> +++ b/drivers/usb/chipidea/ci.h
> @@ -130,6 +130,7 @@ struct hw_bank {
> * @transceiver: pointer to USB PHY, if any
> * @hcd: pointer to usb_hcd for ehci host driver
> * @otg: for otg support
> + * @events: events for otg, and handled at ci_role_work
> */
> struct ci13xxx {
> struct device *dev;
> @@ -140,6 +141,7 @@ struct ci13xxx {
> enum ci_role role;
> bool is_otg;
> struct work_struct work;
> + struct delayed_work dwork;
> struct workqueue_struct *wq;
>
> struct dma_pool *qh_pool;
> @@ -165,7 +167,9 @@ struct ci13xxx {
> bool global_phy;
> struct usb_phy *transceiver;
> struct usb_hcd *hcd;
> - struct usb_otg otg;
> + struct usb_otg otg;
> + bool id_event;
> + bool b_sess_valid_event;
> };
>
> static inline struct ci_role_driver *ci_role(struct ci13xxx *ci)
> @@ -314,4 +318,6 @@ int hw_port_test_set(struct ci13xxx *ci, u8 mode);
>
> u8 hw_port_test_get(struct ci13xxx *ci);
>
> +void ci_handle_vbus_change(struct ci13xxx *ci);
> +
> #endif /* __DRIVERS_USB_CHIPIDEA_CI_H */
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index aebf695..f8f8484 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -73,6 +73,7 @@
> #include "bits.h"
> #include "host.h"
> #include "debug.h"
> +#include "otg.h"
>
> /* Controller register map */
> static uintptr_t ci_regs_nolpm[] = {
> @@ -199,6 +200,14 @@ static int hw_device_init(struct ci13xxx *ci, void __iomem *base)
> if (ci->hw_ep_max > ENDPT_MAX)
> return -ENODEV;
>
> + /* Disable all interrupts bits */
> + hw_write(ci, OP_USBINTR, 0xffffffff, 0);
> + ci_disable_otg_interrupt(ci, OTGSC_INT_EN_BITS);
> +
> + /* Clear all interrupts status bits*/
> + hw_write(ci, OP_USBSTS, 0xffffffff, 0xffffffff);
> + ci_clear_otg_interrupt(ci, OTGSC_INT_STATUS_BITS);
> +
> dev_dbg(ci->dev, "ChipIdea HDRC found, lpm: %d; cap: %p op: %p\n",
> ci->hw_bank.lpm, ci->hw_bank.cap, ci->hw_bank.op);
>
> @@ -265,24 +274,124 @@ static enum ci_role ci_otg_role(struct ci13xxx *ci)
> }
>
> /**
> - * ci_role_work - perform role changing based on ID pin
> - * @work: work struct
> + * hw_wait_reg: wait the register value
> + *
> + * Sometimes, it needs to wait register value before going on.
> + * Eg, when switch to device mode, the vbus value should be lower
> + * than OTGSC_BSV before connects to host.
> + *
> + * @ci: the controller
> + * @reg: register index
> + * @mask: mast bit
> + * @value: the bit value to wait
> + * @timeout: timeout to indicate an error
> + *
> + * This function returns an error code if timeout
> */
> -static void ci_role_work(struct work_struct *work)
> +static int hw_wait_reg(struct ci13xxx *ci, enum ci13xxx_regs reg, u32 mask,
> + u32 value, unsigned long timeout)
> +{
> + unsigned long elapse = jiffies + timeout;
> +
> + while (hw_read(ci, reg, mask) != value) {
> + if (time_after(jiffies, elapse)) {
> + dev_err(ci->dev, "timeout waiting for %08x in %d\n",
> + mask, reg);
> + return -ETIMEDOUT;
> + }
> + msleep(20);
> + }
> +
> + return 0;
> +}
> +
> +#define CI_VBUS_STABLE_TIMEOUT 500
> +static void ci_handle_id_switch(struct ci13xxx *ci)
> {
> - struct ci13xxx *ci = container_of(work, struct ci13xxx, work);
> enum ci_role role = ci_otg_role(ci);
>
> if (role != ci->role) {
> dev_dbg(ci->dev, "switching from %s to %s\n",
> ci_role(ci)->name, ci->roles[role]->name);
>
> - ci_role_stop(ci);
> - ci_role_start(ci, role);
> - enable_irq(ci->irq);
> + /* 1. Finish the current role */
> + if (ci->role == CI_ROLE_GADGET) {
> + usb_gadget_vbus_disconnect(&ci->gadget);
> + /* host doesn't care B_SESSION_VALID event */
> + ci_clear_otg_interrupt(ci, OTGSC_BSVIS);
> + ci_disable_otg_interrupt(ci, OTGSC_BSVIE);
> + ci->role = CI_ROLE_END;
> + /* reset controller */
> + hw_device_reset(ci, USBMODE_CM_IDLE);
> + } else if (ci->role == CI_ROLE_HOST) {
> + ci_role_stop(ci);
> + /* reset controller */
> + hw_device_reset(ci, USBMODE_CM_IDLE);
> + }
> +
> + /* 2. Turn on/off vbus according to coming role */
> + if (ci_otg_role(ci) == CI_ROLE_GADGET) {
> + otg_set_vbus(&ci->otg, false);
> + /* wait vbus lower than OTGSC_BSV */
> + hw_wait_reg(ci, OP_OTGSC, OTGSC_BSV, 0,
> + CI_VBUS_STABLE_TIMEOUT);
> + } else if (ci_otg_role(ci) == CI_ROLE_HOST) {
> + otg_set_vbus(&ci->otg, true);
> + /* wait vbus higher than OTGSC_AVV */
> + hw_wait_reg(ci, OP_OTGSC, OTGSC_AVV, OTGSC_AVV,
> + CI_VBUS_STABLE_TIMEOUT);
> + }
> +
> + /* 3. Begin the new role */
> + if (ci_otg_role(ci) == CI_ROLE_GADGET) {
> + ci->role = role;
> + ci_clear_otg_interrupt(ci, OTGSC_BSVIS);
> + ci_enable_otg_interrupt(ci, OTGSC_BSVIE);
> + } else if (ci_otg_role(ci) == CI_ROLE_HOST) {
> + ci_role_start(ci, role);
> + }
> }
> }
>
> +void ci_handle_vbus_change(struct ci13xxx *ci)
> +{
> + u32 otgsc = hw_read(ci, OP_OTGSC, ~0);
> +
> + if (otgsc & OTGSC_BSV)
> + usb_gadget_vbus_connect(&ci->gadget);
> + else
> + usb_gadget_vbus_disconnect(&ci->gadget);
> +}
> +
> +/**
> + * ci_otg_work - perform otg (vbus/id) event handle
> + * @work: work struct
> + */
> +static void ci_otg_work(struct work_struct *work)
> +{
> + struct ci13xxx *ci = container_of(work, struct ci13xxx, work);
> +
> + if (ci->id_event) {
> + ci->id_event = false;
> + ci_handle_id_switch(ci);
> + } else if (ci->b_sess_valid_event) {
> + ci->b_sess_valid_event = false;
> + ci_handle_vbus_change(ci);
> + } else
> + dev_err(ci->dev, "unexpected event occurs at %s\n", __func__);
> +
> + enable_irq(ci->irq);
> +}
> +
> +static void ci_delayed_work(struct work_struct *work)
> +{
> + struct delayed_work *dwork = to_delayed_work(work);
> + struct ci13xxx *ci = container_of(dwork, struct ci13xxx, dwork);
> +
> + otg_set_vbus(&ci->otg, true);
> +
> +}
> +
> static ssize_t show_role(struct device *dev, struct device_attribute *attr,
> char *buf)
> {
> @@ -321,19 +430,36 @@ static irqreturn_t ci_irq(int irq, void *data)
> irqreturn_t ret = IRQ_NONE;
> u32 otgsc = 0;
>
> - if (ci->is_otg)
> - otgsc = hw_read(ci, OP_OTGSC, ~0);
> + otgsc = hw_read(ci, OP_OTGSC, ~0);
My spec says that in non-otg implementations OTGSC is reserved. We
probably shouldn't try any of this for such devices.
>
> - if (ci->role != CI_ROLE_END)
> - ret = ci_role(ci)->irq(ci);
> + /*
> + * Handle id change interrupt, it indicates device/host function
> + * switch.
> + */
> + if (ci->is_otg && (otgsc & OTGSC_IDIE) && (otgsc & OTGSC_IDIS)) {
> + ci->id_event = true;
> + ci_clear_otg_interrupt(ci, OTGSC_IDIS);
> + disable_irq_nosync(ci->irq);
> + queue_work(ci->wq, &ci->work);
> + return IRQ_HANDLED;
> + }
>
> - if (ci->is_otg && (otgsc & OTGSC_IDIS)) {
> - hw_write(ci, OP_OTGSC, OTGSC_IDIS, OTGSC_IDIS);
> + /*
> + * Handle vbus change interrupt, it indicates device connection
> + * and disconnection events.
> + */
> + if ((otgsc & OTGSC_BSVIE) && (otgsc & OTGSC_BSVIS)) {
> + ci->b_sess_valid_event = true;
> + ci_clear_otg_interrupt(ci, OTGSC_BSVIS);
> disable_irq_nosync(ci->irq);
> queue_work(ci->wq, &ci->work);
> - ret = IRQ_HANDLED;
> + return IRQ_HANDLED;
> }
>
> + /* Handle device/host interrupt */
> + if (ci->role != CI_ROLE_END)
> + ret = ci_role(ci)->irq(ci);
> +
> return ret;
> }
>
> @@ -398,6 +524,7 @@ static int ci_hdrc_probe(struct platform_device *pdev)
> struct resource *res;
> void __iomem *base;
> int ret;
> + u32 otgsc;
>
> if (!dev->platform_data) {
> dev_err(dev, "platform data missing\n");
> @@ -443,7 +570,8 @@ static int ci_hdrc_probe(struct platform_device *pdev)
> return -ENODEV;
> }
>
> - INIT_WORK(&ci->work, ci_role_work);
> + INIT_WORK(&ci->work, ci_otg_work);
> + INIT_DELAYED_WORK(&ci->dwork, ci_delayed_work);
> ci->wq = create_singlethread_workqueue("ci_otg");
> if (!ci->wq) {
> dev_err(dev, "can't create workqueue\n");
> @@ -466,7 +594,10 @@ static int ci_hdrc_probe(struct platform_device *pdev)
> }
>
> if (ci->roles[CI_ROLE_HOST] && ci->roles[CI_ROLE_GADGET]) {
> + dev_dbg(dev, "support otg\n");
> ci->is_otg = true;
> + /* if otg is supported, create struct usb_otg */
> + ci_hdrc_otg_init(ci);
> /* ID pin needs 1ms debouce time, we delay 2ms for safe */
> mdelay(2);
> ci->role = ci_otg_role(ci);
> @@ -483,6 +614,17 @@ static int ci_hdrc_probe(struct platform_device *pdev)
> goto rm_wq;
> }
>
> + otgsc = hw_read(ci, OP_OTGSC, ~0);
> + /*
> + * if it is device mode:
> + * - Enable vbus detect
> + * - If it has already connected to host, notify udc
> + */
> + if (ci->role == CI_ROLE_GADGET) {
> + ci_enable_otg_interrupt(ci, OTGSC_BSVIE);
We should only do this for otg capable devices, otherwise OTGSC is
reserved.
> + ci_handle_vbus_change(ci);
Shouldn't this be part of the gadget role start like I suggested a
couple of months back? Maybe ci_enable_otg_interrupt() can go there too.
> + }
> +
> platform_set_drvdata(pdev, ci);
> ret = request_irq(ci->irq, ci_irq, IRQF_SHARED, ci->platdata->name,
> ci);
> @@ -493,8 +635,9 @@ static int ci_hdrc_probe(struct platform_device *pdev)
> if (ret)
> goto rm_attr;
>
> - if (ci->is_otg)
> - hw_write(ci, OP_OTGSC, OTGSC_IDIE, OTGSC_IDIE);
> + /* Handle the situation that usb device at the MicroB to A cable */
> + if (ci->is_otg && !(otgsc & OTGSC_ID))
> + queue_delayed_work(ci->wq, &ci->dwork, msecs_to_jiffies(500));
>
> return ret;
>
> diff --git a/drivers/usb/chipidea/otg.c b/drivers/usb/chipidea/otg.c
> index 7dea3b3..2986d91 100644
> --- a/drivers/usb/chipidea/otg.c
> +++ b/drivers/usb/chipidea/otg.c
> @@ -10,21 +10,28 @@
> * published by the Free Software Foundation.
> */
>
> -#include <linux/platform_device.h>
> -#include <linux/module.h>
> -#include <linux/io.h>
> -#include <linux/irq.h>
> -#include <linux/kernel.h>
> -#include <linux/slab.h>
> -#include <linux/usb/gadget.h>
> #include <linux/usb/otg.h>
> +#include <linux/usb/gadget.h>
> #include <linux/usb/chipidea.h>
>
> #include "ci.h"
> -#include "udc.h"
> #include "bits.h"
> -#include "host.h"
> -#include "debug.h"
> +
> +void ci_clear_otg_interrupt(struct ci13xxx *ci, u32 bits)
> +{
> + /* Only clear request bits */
> + hw_write(ci, OP_OTGSC, OTGSC_INT_STATUS_BITS, bits);
> +}
> +
> +void ci_enable_otg_interrupt(struct ci13xxx *ci, u32 bits)
> +{
> + hw_write(ci, OP_OTGSC, bits, bits);
> +}
> +
> +void ci_disable_otg_interrupt(struct ci13xxx *ci, u32 bits)
> +{
> + hw_write(ci, OP_OTGSC, bits, 0);
> +}
>
> static int ci_otg_set_peripheral(struct usb_otg *otg,
> struct usb_gadget *periph)
> @@ -55,6 +62,7 @@ int ci_hdrc_otg_init(struct ci13xxx *ci)
> ci->otg.set_host = ci_otg_set_host;
> if (!IS_ERR_OR_NULL(ci->transceiver))
> ci->transceiver->otg = &ci->otg;
> + ci_enable_otg_interrupt(ci, OTGSC_IDIE);
>
> return 0;
> }
> diff --git a/drivers/usb/chipidea/otg.h b/drivers/usb/chipidea/otg.h
> index b4c6b3e..fa30428 100644
> --- a/drivers/usb/chipidea/otg.h
> +++ b/drivers/usb/chipidea/otg.h
> @@ -2,5 +2,8 @@
> #define __DRIVERS_USB_CHIPIDEA_OTG_H
>
> int ci_hdrc_otg_init(struct ci13xxx *ci);
> +void ci_clear_otg_interrupt(struct ci13xxx *ci, u32 bits);
> +void ci_enable_otg_interrupt(struct ci13xxx *ci, u32 bits);
> +void ci_disable_otg_interrupt(struct ci13xxx *ci, u32 bits);
>
> #endif /* __DRIVERS_USB_CHIPIDEA_OTG_H */
> diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> index d214448..83e54bb 100644
> --- a/drivers/usb/chipidea/udc.c
> +++ b/drivers/usb/chipidea/udc.c
> @@ -1371,6 +1371,7 @@ static int ci13xxx_vbus_session(struct usb_gadget *_gadget, int is_active)
> pm_runtime_get_sync(&_gadget->dev);
> hw_device_reset(ci, USBMODE_CM_DC);
> hw_device_state(ci, ci->ep0out->qh.dma);
> + dev_dbg(ci->dev, "Connected to host\n");
> } else {
> hw_device_state(ci, 0);
> if (ci->platdata->notify_event)
> @@ -1378,6 +1379,7 @@ static int ci13xxx_vbus_session(struct usb_gadget *_gadget, int is_active)
> CI13XXX_CONTROLLER_STOPPED_EVENT);
> _gadget_stop_activity(&ci->gadget);
> pm_runtime_put_sync(&_gadget->dev);
> + dev_dbg(ci->dev, "Disconnected from host\n");
> }
> }
>
> --
> 1.7.0.4
^ permalink raw reply
* [PATCH 2/4] drm/i2c: nxp-tda998x (v2)
From: Rob Clark @ 2013-01-24 14:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130124115720.GV31870@phenom.ffwll.local>
On Thu, Jan 24, 2013 at 5:57 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, Jan 22, 2013 at 04:36:23PM -0600, Rob Clark wrote:
>> Driver for the NXP TDA998X i2c hdmi encoder slave.
>>
>> v1: original
>> v2: fix npix/nline programming
>>
>> Signed-off-by: Rob Clark <robdclark@gmail.com>
>
> Just one bikeshed, otherwise
>
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>
> [cut]
>
>> +static void
>> +reg_set(struct drm_encoder *encoder, uint16_t reg, uint8_t val)
>> +{
>> + reg_write(encoder, reg, reg_read(encoder, reg) | val);
>> +}
>> +
>> +static void
>> +reg_clear(struct drm_encoder *encoder, uint16_t reg, uint8_t val)
>> +{
>> + reg_write(encoder, reg, reg_read(encoder, reg) & ~val);
>> +}
>
> What about drivers/base/regmap? I haven't looked to closely yet and never
> used it in code, but there's a presentation [1] and it sounds like it
> provides some nice (and more important standardized) helper stuff for
> debug, tracing, ...
>
> Since encoder slave drivers tend to be utterly boring register bashing and
> we expect tons of time, I think high levels of standardization would be
> really useful. Care to look into this a bit?
I did look at regmap.. what convinced me against using it was that if
you don't use cached mode, it ends up writing the page selector
register for every read/write. And I don't have enough actual
documentation about this nxp part to know the reset values of all the
registers in order to use caching.
BR,
-R
> Cheers, Daniel
>
> 1: http://free-electrons.com/blog/fosdem2012-videos/
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* [PATCH 3/4] drm/tilcdc: add encoder slave
From: Rob Clark @ 2013-01-24 14:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130124124323.GA31306@phenom.ffwll.local>
On Thu, Jan 24, 2013 at 6:43 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, Jan 22, 2013 at 04:36:24PM -0600, Rob Clark wrote:
>> Add output panel driver for i2c encoder slaves.
>>
>> Signed-off-by: Rob Clark <robdclark@gmail.com>
>
> A few questions below, otherwise
>
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
>> ---
[snip]
>> diff --git a/drivers/gpu/drm/tilcdc/Kconfig b/drivers/gpu/drm/tilcdc/Kconfig
>> index ee9b592..99beca2 100644
>> --- a/drivers/gpu/drm/tilcdc/Kconfig
>> +++ b/drivers/gpu/drm/tilcdc/Kconfig
>> @@ -8,3 +8,15 @@ config DRM_TILCDC
>> Choose this option if you have an TI SoC with LCDC display
>> controller, for example AM33xx in beagle-bone, DA8xx, or
>> OMAP-L1xx. This driver replaces the FB_DA8XX fbdev driver.
>> +
>> +menu "I2C encoder or helper chips"
>> + depends on DRM && DRM_KMS_HELPER && I2C
>> +
>> +config DRM_I2C_NXP_TDA998X
>> + tristate "NXP Semiconductors TDA998X HDMI encoder"
>> + default m if DRM_TILCDC
>> + help
>> + Support for NXP Semiconductors TDA998X HDMI encoders.
>> +
>> +endmenu
>> +
>
> Shouldn't that hunk be in patch 2?
yeah, probably.. I just copied how it was done in nouveau, but I think
probably the Kconfig for the i2c encoder slaves should be moved into
drivers/gpu/drm/i2c
[snip]
>> +/*
>> + * Encoder:
>> + */
>> +
>> +struct slave_encoder {
>> + struct drm_encoder_slave base;
>> + struct slave_module *mod;
>> +};
>> +#define to_slave_encoder(x) container_of(to_encoder_slave(x), struct slave_encoder, base)
>
> Since you have a 1:1:1 relationship between module/drm_encoder, the
> drm_encoder_slave and the connector I'd just smash this all into one
> struct. Pure bikeshed though ;-)
yeah, but drm_encoder_slave is coming from drm core
[snip]
>> +static struct drm_encoder *slave_encoder_create(struct drm_device *dev,
>> + struct slave_module *mod)
>> +{
>> + struct slave_encoder *slave_encoder;
>> + struct drm_encoder *encoder;
>> + int ret;
>> +
>> + slave_encoder = kzalloc(sizeof(*slave_encoder), GFP_KERNEL);
>> + if (!slave_encoder) {
>> + dev_err(dev->dev, "allocation failed\n");
>> + return NULL;
>> + }
>> +
>> + slave_encoder->mod = mod;
>> +
>> + encoder = &slave_encoder->base.base;
>> + encoder->possible_crtcs = 1;
>> +
>> + ret = drm_encoder_init(dev, encoder, &slave_encoder_funcs,
>> + DRM_MODE_ENCODER_LVDS);
>
> DRM_MODE_ENCODER_TMDS? Although I guess adding a new kind of
> multi-function encoder type would make more sense and also useful in other
> places. E.g. i915-sdvo/dvo just set meaningless types for multi-function
> encoders (i.e. more than one connector on the same output), namely the
> type which matches the connector last initalized.
I suppose TDMS makes more sense.. perhaps getting both this and
connector type from the encoder-slave would make the most sense, but I
can change it to TDMS for now
[snip]
>> +static struct drm_connector *slave_connector_create(struct drm_device *dev,
>> + struct slave_module *mod, struct drm_encoder *encoder)
>> +{
>> + struct slave_connector *slave_connector;
>> + struct drm_connector *connector;
>> + int ret;
>> +
>> + slave_connector = kzalloc(sizeof(*slave_connector), GFP_KERNEL);
>> + if (!slave_connector) {
>> + dev_err(dev->dev, "allocation failed\n");
>> + return NULL;
>> + }
>> +
>> + slave_connector->encoder = encoder;
>> + slave_connector->mod = mod;
>> +
>> + connector = &slave_connector->base;
>> +
>> + drm_connector_init(dev, connector, &slave_connector_funcs,
>> + DRM_MODE_CONNECTOR_HDMIA);
>
> Shouldn't we get the connector type from the drm_encoder_slave somehow?
> Works here for now, so just food for thought for future encoder slave
> refactorings and infrastructure work.
yeah, getting it from the encoder slave makes the most sense
[snip]
>> +static struct of_device_id slave_of_match[] = {
>> + { .compatible = "tilcdc,slave", },
>> + { },
>> +};
>> +MODULE_DEVICE_TABLE(of, slave_of_match);
>> +
>> +struct platform_driver slave_driver = {
>> + .probe = slave_probe,
>> + .remove = slave_remove,
>> + .driver = {
>> + .owner = THIS_MODULE,
>> + .name = "slave",
>> + .of_match_table = slave_of_match,
>> + },
>> +};
>
> No idea how this devicetree matching stuff is supposed to work, but I
> guess this needs to be updated in the devictree docs like the base match.
yeah, I didn't realize previously about the DT bindings docs, so I
need to look into that
BR,
-R
^ permalink raw reply
* [PATCH 3/4] drm/tilcdc: add encoder slave
From: Rob Clark @ 2013-01-24 14:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130124130114.GB31306@phenom.ffwll.local>
On Thu, Jan 24, 2013 at 7:01 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, Jan 22, 2013 at 04:36:24PM -0600, Rob Clark wrote:
>> Add output panel driver for i2c encoder slaves.
>>
>> Signed-off-by: Rob Clark <robdclark@gmail.com>
>
> Found some more stuff ...
>
> [cut]
>
>> +static const struct drm_encoder_helper_funcs slave_encoder_helper_funcs = {
>> + .dpms = drm_i2c_encoder_dpms,
>> + .mode_fixup = drm_i2c_encoder_mode_fixup,
>> + .prepare = slave_encoder_prepare,
>> + .commit = drm_i2c_encoder_commit,
>> + .mode_set = drm_i2c_encoder_mode_set,
>> + .save = drm_i2c_encoder_save,
>> + .restore = drm_i2c_encoder_restore,
>> +};
>
> I couldn't find these wrappers anywhere ...
this is in one of the dependent patches (also on my tilcdc-next branch):
https://patchwork.kernel.org/patch/1950971/
I also cleaned up nouveau to use 'em:
https://patchwork.kernel.org/patch/1951051/
>> +
>> +static const struct i2c_board_info info = {
>> + I2C_BOARD_INFO("tda998x", 0x70)
>> +};
>
> Shouldn't there be some of/devicetree thing to tell us which one to load?
There are limited options for the i2c addresses, and all the boards
I've seen which have this part are at 0x70 and 0x34 for CEC. Probably
the CEC address needs to come from a config struct or maybe the i2c
encoder just gets passed a 'struct device_node *'. I'm not really
sure the best way to handle that to share the encoder between DT and
non-DT platforms, and since I didn't really need the configurability
yet, I just left that for now and decided we could figure out how to
handle that as the need arose.
BR,
-R
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
^ permalink raw reply
* [PATCH v6 02/15] ARM: Section based HYP idmap
From: Catalin Marinas @ 2013-01-24 14:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130116175734.29147.19552.stgit@ubuntu>
On Wed, Jan 16, 2013 at 05:57:34PM +0000, Christoffer Dall wrote:
> --- a/arch/arm/mm/idmap.c
> +++ b/arch/arm/mm/idmap.c
> @@ -1,4 +1,6 @@
> +#include <linux/module.h>
Minor thing - do you need to include linux/module.h here?
> + identity_mapping_add(hyp_pgd, __hyp_idmap_text_start,
> + __hyp_idmap_text_end, PMD_SECT_AP1);
It would be more consistent if you define PMD_SECT_HYP or something like
that. I think you have a L_PTE_HYP bit as well.
--
Catalin
^ permalink raw reply
* [RESEND PATCH v5 4/7] usb: chipidea: consolidate ci_role_driver's API for both roles
From: Alexander Shishkin @ 2013-01-24 14:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358733418-17969-5-git-send-email-peter.chen@freescale.com>
Peter Chen <peter.chen@freescale.com> writes:
> - Create init/destroy API for probe and remove
> - start/stop API are only used otg id switch process
> - Create the gadget at ci_hdrc_probe if the gadget is supported
> at that port, the main purpose for this is to avoid gadget module
> load fail at init.rc
I don't think it's necessary to mention android-specific init scripts
here in our patches.
> Signed-off-by: Peter Chen <peter.chen@freescale.com>
> ---
> drivers/usb/chipidea/ci.h | 19 +++++++++++-
> drivers/usb/chipidea/core.c | 65 ++++++++++++++++++------------------------
> drivers/usb/chipidea/host.c | 2 +
> drivers/usb/chipidea/udc.c | 33 ++++++++++++++++++++-
> 4 files changed, 78 insertions(+), 41 deletions(-)
>
> diff --git a/drivers/usb/chipidea/ci.h b/drivers/usb/chipidea/ci.h
> index 325d790..00939e6 100644
> --- a/drivers/usb/chipidea/ci.h
> +++ b/drivers/usb/chipidea/ci.h
> @@ -67,14 +67,18 @@ enum ci_role {
>
> /**
> * struct ci_role_driver - host/gadget role driver
> - * start: start this role
> - * stop: stop this role
> + * init: init this role (used at module probe)
> + * start: start this role (used at id switch)
> + * stop: stop this role (used at id switch)
> + * destroy: destroy this role (used at module remove)
> * irq: irq handler for this role
> * name: role name string (host/gadget)
> */
> struct ci_role_driver {
> + int (*init)(struct ci13xxx *);
> int (*start)(struct ci13xxx *);
> void (*stop)(struct ci13xxx *);
> + void (*destroy)(struct ci13xxx *);
> irqreturn_t (*irq)(struct ci13xxx *);
> const char *name;
> };
> @@ -206,6 +210,17 @@ static inline void ci_role_stop(struct ci13xxx *ci)
> ci->roles[role]->stop(ci);
> }
>
> +static inline void ci_role_destroy(struct ci13xxx *ci)
> +{
> + enum ci_role role = ci->role;
> +
> + if (role == CI_ROLE_END)
> + return;
> +
> + ci->role = CI_ROLE_END;
> +
> + ci->roles[role]->destroy(ci);
> +}
What does this do? It should take role an a parameter, at least. Or it
can be called ci_roles_destroy() and, well, destroy all the roles. Now
we're in a situation where we destroy one.
The idea is that, with this api, we can (and should) have both roles
allocated all the time, but only one role start()'ed.
What we can do here is move the udc's .init() code to
ci_hdrc_gadget_init() and add a complementary ci_hdrc_gadget_destroy(),
which we call in ci_hdrc_remove() and probe's error path. And we can
probably do something similar for the host, or just leave it as it is
now. Seems simpler to me.
> /******************************************************************************
> * REGISTERS
> *****************************************************************************/
> diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
> index f8f8484..a5adf1a 100644
> --- a/drivers/usb/chipidea/core.c
> +++ b/drivers/usb/chipidea/core.c
> @@ -315,27 +315,16 @@ static void ci_handle_id_switch(struct ci13xxx *ci)
> ci_role(ci)->name, ci->roles[role]->name);
>
> /* 1. Finish the current role */
> - if (ci->role == CI_ROLE_GADGET) {
> - usb_gadget_vbus_disconnect(&ci->gadget);
> - /* host doesn't care B_SESSION_VALID event */
> - ci_clear_otg_interrupt(ci, OTGSC_BSVIS);
> - ci_disable_otg_interrupt(ci, OTGSC_BSVIE);
> - ci->role = CI_ROLE_END;
> - /* reset controller */
> - hw_device_reset(ci, USBMODE_CM_IDLE);
> - } else if (ci->role == CI_ROLE_HOST) {
> - ci_role_stop(ci);
> - /* reset controller */
> - hw_device_reset(ci, USBMODE_CM_IDLE);
> - }
> + ci_role_stop(ci);
> + hw_device_reset(ci, USBMODE_CM_IDLE);
>
> /* 2. Turn on/off vbus according to coming role */
> - if (ci_otg_role(ci) == CI_ROLE_GADGET) {
> + if (role == CI_ROLE_GADGET) {
> otg_set_vbus(&ci->otg, false);
> /* wait vbus lower than OTGSC_BSV */
> hw_wait_reg(ci, OP_OTGSC, OTGSC_BSV, 0,
> CI_VBUS_STABLE_TIMEOUT);
> - } else if (ci_otg_role(ci) == CI_ROLE_HOST) {
> + } else if (role == CI_ROLE_HOST) {
> otg_set_vbus(&ci->otg, true);
> /* wait vbus higher than OTGSC_AVV */
> hw_wait_reg(ci, OP_OTGSC, OTGSC_AVV, OTGSC_AVV,
> @@ -343,13 +332,7 @@ static void ci_handle_id_switch(struct ci13xxx *ci)
> }
>
> /* 3. Begin the new role */
> - if (ci_otg_role(ci) == CI_ROLE_GADGET) {
> - ci->role = role;
> - ci_clear_otg_interrupt(ci, OTGSC_BSVIS);
> - ci_enable_otg_interrupt(ci, OTGSC_BSVIE);
> - } else if (ci_otg_role(ci) == CI_ROLE_HOST) {
> - ci_role_start(ci, role);
> - }
> + ci_role_start(ci, role);
> }
> }
>
> @@ -585,7 +568,7 @@ static int ci_hdrc_probe(struct platform_device *pdev)
>
> ret = ci_hdrc_gadget_init(ci);
> if (ret)
> - dev_info(dev, "doesn't support gadget\n");
> + dev_info(dev, "doesn't support gadget, ret=%d\n", ret);
>
> if (!ci->roles[CI_ROLE_HOST] && !ci->roles[CI_ROLE_GADGET]) {
> dev_err(dev, "no supported roles\n");
> @@ -607,22 +590,30 @@ static int ci_hdrc_probe(struct platform_device *pdev)
> : CI_ROLE_GADGET;
> }
>
> - ret = ci_role_start(ci, ci->role);
> - if (ret) {
> - dev_err(dev, "can't start %s role\n", ci_role(ci)->name);
> - ret = -ENODEV;
> - goto rm_wq;
> - }
> -
> otgsc = hw_read(ci, OP_OTGSC, ~0);
> +
> /*
> - * if it is device mode:
> - * - Enable vbus detect
> - * - If it has already connected to host, notify udc
> + * If the gadget is supported, call its init unconditionally,
> + * We need to support load gadget module at init.rc.
> */
> - if (ci->role == CI_ROLE_GADGET) {
> - ci_enable_otg_interrupt(ci, OTGSC_BSVIE);
> - ci_handle_vbus_change(ci);
> + if (ci->roles[CI_ROLE_GADGET]) {
> + ret = ci->roles[CI_ROLE_GADGET]->init(ci);
> + if (ret) {
> + dev_err(dev, "can't init %s role, ret=%d\n",
> + ci_role(ci)->name, ret);
> + ret = -ENODEV;
> + goto rm_wq;
> + }
> + }
> +
> + if (ci->role == CI_ROLE_HOST) {
> + ret = ci->roles[CI_ROLE_HOST]->init(ci);
> + if (ret) {
> + dev_err(dev, "can't init %s role, ret=%d\n",
> + ci_role(ci)->name, ret);
> + ret = -ENODEV;
> + goto rm_wq;
> + }
> }
>
> platform_set_drvdata(pdev, ci);
> @@ -660,7 +651,7 @@ static int ci_hdrc_remove(struct platform_device *pdev)
> destroy_workqueue(ci->wq);
> device_remove_file(ci->dev, &dev_attr_role);
> free_irq(ci->irq, ci);
> - ci_role_stop(ci);
> + ci_role_destroy(ci);
>
> return 0;
> }
> diff --git a/drivers/usb/chipidea/host.c b/drivers/usb/chipidea/host.c
> index caecad9..6024a4f 100644
> --- a/drivers/usb/chipidea/host.c
> +++ b/drivers/usb/chipidea/host.c
> @@ -92,8 +92,10 @@ int ci_hdrc_host_init(struct ci13xxx *ci)
> if (!rdrv)
> return -ENOMEM;
>
> + rdrv->init = host_start;
> rdrv->start = host_start;
> rdrv->stop = host_stop;
> + rdrv->destroy = host_stop;
Will this allocate the hcd twice if we start in host role? Looks like that.
> rdrv->irq = host_irq;
> rdrv->name = "host";
> ci->roles[CI_ROLE_HOST] = rdrv;
> diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
> index 83e54bb..e6a4ec0 100644
> --- a/drivers/usb/chipidea/udc.c
> +++ b/drivers/usb/chipidea/udc.c
> @@ -31,6 +31,7 @@
>
> #include "ci.h"
> #include "udc.h"
> +#include "otg.h"
> #include "bits.h"
> #include "debug.h"
>
> @@ -1754,6 +1755,16 @@ static int udc_start(struct ci13xxx *ci)
> pm_runtime_no_callbacks(&ci->gadget.dev);
> pm_runtime_enable(&ci->gadget.dev);
>
> + /*
> + * if it is device mode:
> + * - Enable vbus detect
> + * - If it has already connected to host, notify udc
> + */
> + if (ci->role == CI_ROLE_GADGET) {
> + ci_enable_otg_interrupt(ci, OTGSC_BSVIE);
> + ci_handle_vbus_change(ci);
> + }
> +
> return retval;
>
> remove_trans:
> @@ -1780,6 +1791,22 @@ free_qh_pool:
> return retval;
> }
>
> +static int udc_id_switch_for_device(struct ci13xxx *ci)
> +{
> + ci_clear_otg_interrupt(ci, OTGSC_BSVIS);
> + ci_enable_otg_interrupt(ci, OTGSC_BSVIE);
> +
> + return 0;
> +}
> +
> +static void udc_id_switch_for_host(struct ci13xxx *ci)
> +{
> + usb_gadget_vbus_disconnect(&ci->gadget);
> + /* host doesn't care B_SESSION_VALID event */
> + ci_clear_otg_interrupt(ci, OTGSC_BSVIS);
> + ci_disable_otg_interrupt(ci, OTGSC_BSVIE);
> +}
> +
> /**
> * udc_remove: parent remove must call this to remove UDC
> *
> @@ -1825,8 +1852,10 @@ int ci_hdrc_gadget_init(struct ci13xxx *ci)
> if (!rdrv)
> return -ENOMEM;
>
> - rdrv->start = udc_start;
> - rdrv->stop = udc_stop;
> + rdrv->init = udc_start;
> + rdrv->start = udc_id_switch_for_device;
> + rdrv->stop = udc_id_switch_for_host;
> + rdrv->destroy = udc_stop;
> rdrv->irq = udc_irq;
> rdrv->name = "gadget";
> ci->roles[CI_ROLE_GADGET] = rdrv;
> --
> 1.7.0.4
^ permalink raw reply
* [kvmarm] [GIT PULL] KVM/ARM core implementation
From: Marc Zyngier @ 2013-01-24 14:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CANM98qLq5wfuUWHmjn_SHG=f1O9kG_cgwpA2VfOy5y4t0m-52Q@mail.gmail.com>
On Wed, 23 Jan 2013 14:22:23 -0500, Christoffer Dall
<c.dall@virtualopensystems.com> wrote:
> Hi Will,
>
> I've prepared a stable branch for you, for-will/kvm/core, based on
> your stable perf branch.
>
> Since the last patch series, I've addressed the reviewer comments, and
> rev'ed KVM_CAP_ARM_PSCI to 87, since 86 is already used by PPC in
> kvm/next.
>
> kvmtool should probably be updated acoordingly.
>
> I rebased the VGIC and the Arch. Timers series on the stable branch
> and made these available in kvm/vgic and kvm/vgic-timers,
> respectively. These branches are, however, not yet stable.
FWIW, I've now created a kvm-arm/vgic branch, based on for-will/kvm/core
and arm-soc's irqchip/gic-vic-move.
Not much has changed, apart from the obvious include paths and an
additional guard in arm-gic.h. This should definitely be stable now.
The timer code is currently blocked by the lack of a stable branch for the
broadcast stuff.
M.
--
Fast, cheap, reliable. Pick two.
^ permalink raw reply
* [RFC PATCH 6/6] ARM: kirkwood: consolidate mv643xx_eth init for DT
From: Jason Cooper @ 2013-01-24 14:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51013933.9020601@openwrt.org>
On Thu, Jan 24, 2013 at 02:37:55PM +0100, Florian Fainelli wrote:
> Hello Jason,
>
> On 01/24/2013 12:34 AM, Jason Cooper wrote:
> >replace a lot of unneeded code and files with a lookup table.
>
> Would not it be better to keep all of this as-is and merge/improve
> Ian's mv643xx_eth device tree bindings [1], and then only remove
> these files? It is just 81 new lines, so it is not a big deal, just
> wondering here what is best.
I agree, however, there is a long history with that patch. That driver
has been in use by powerpc for many years. We need to be mindful not to
break existing installations. I don't think it'll be ready in time for
v3.9. So, I'd like to do the cleanup now.
thx,
Jason.
> [1]: http://patchwork.ozlabs.org/patch/175652/
^ permalink raw reply
* [kvmarm] [Qemu-devel] [RFC] Virtio-desktop: Virtio-based virtual desktop
From: Alexander Graf @ 2013-01-24 14:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130124092531.GD18072@stefanha-thinkpad.redhat.com>
On 24.01.2013, at 10:25, Stefan Hajnoczi wrote:
> On Thu, Jan 24, 2013 at 11:40:24AM +0530, Anup Patel wrote:
>> IMHO, If we have something like Virtio-desktop specification then all
>> possible guest OSes can have support for it and different hypervisor can
>> emulate it without worrying about guest support.
>
> At this point x86 virtualization is mature and working with a mix of
> emulated x86 architecture pieces and virtio devices for
> performance-critical or open-ended functionality that we want to be able
> to extend.
>
> ARM is getting KVM and virtio-mmio support. It will be in a similar
> position soon.
>
> Virtio guest drivers have not been implemented widely. The Linux and
> Windows efforts are driven by the folks who were behind virtio from the
> start, but Solaris, FreeBSD, and others didn't really jump on the virtio
> bandwagon.
>
> Given this landscape, what is the advantage of doing a virtio-desktop?
> It will still need to fall back on ARM or x86 which is already being
> virtualized and emulated.
>
> Depending on how you see it we either have virtio-desktop already or,
> if not, I think the experience with virtio adoption suggests other
> hypervisors and guest OSes will not trip over themselves to implement
> virtio-desktop.
>
> What's the advantage over virtualizating an existing ARM or x86 platform
> and using virtio devices where appropriate?
You don't get changing hardware for changing CPUs. I don't think it makes sense to do a cross-arch virtio-desktop machine type. Different architectures simply have different needs.
But check out the QEMU e500 machine. We have a fully device tree based machine type in the kernel. QEMU drives it by generating a device tree for devices it actually exposes on the fly.
The big advantage we have here is that
1) We don't have to emulate all hardware real hardware emulates
2) We're not restricted to emulate what real hardware emulates. PCI on ARM anyone?
3) Different CPU types can live on the same machine. This is something that x86 is doing already. When you get a SoC, guests are usually guaranteed a core <-> device correlation though.
So overall, having a PV machine makes sense. Having the same common PV machine standardized across different architectures does not make sense.
Alex
^ permalink raw reply
* [RFC PATCH 3/6] ARM: kirkwood: nsa310: cleanup includes and unneeded code
From: Jason Cooper @ 2013-01-24 14:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <51013A73.4090400@openwrt.org>
On Thu, Jan 24, 2013 at 02:43:15PM +0100, Florian Fainelli wrote:
> On 01/24/2013 06:50 AM, Andrew Lunn wrote:
> >On Wed, Jan 23, 2013 at 11:34:21PM +0000, Jason Cooper wrote:
> >>Signed-off-by: Jason Cooper <jason@lakedaemon.net>
> >>---
> >> arch/arm/mach-kirkwood/board-nsa310.c | 9 +--------
> >> 1 file changed, 1 insertion(+), 8 deletions(-)
> >>
> >>diff --git a/arch/arm/mach-kirkwood/board-nsa310.c b/arch/arm/mach-kirkwood/board-nsa310.c
> >>index 1bd328d..0b99533 100644
> >>--- a/arch/arm/mach-kirkwood/board-nsa310.c
> >>+++ b/arch/arm/mach-kirkwood/board-nsa310.c
> >>@@ -10,11 +10,8 @@
> >>
> >> #include <linux/kernel.h>
> >> #include <linux/init.h>
> >>-#include <linux/i2c.h>
> >>-
> >>-#include <asm/mach-types.h>
> >>-#include <asm/mach/arch.h>
> >> #include <mach/kirkwood.h>
> >>+#include <linux/of.h>
> >> #include "common.h"
> >> #include "mpp.h"
> >>
> >>@@ -40,11 +37,7 @@ static unsigned int nsa310_mpp_config[] __initdata = {
> >>
> >> void __init nsa310_init(void)
> >> {
> >>- u32 dev, rev;
> >>-
> >> kirkwood_mpp_conf(nsa310_mpp_config);
> >>-
> >>- kirkwood_pcie_id(&dev, &rev);
> >> }
> >>
> >> static int __init nsa310_pci_init(void)
> >>--
> >>1.8.1.1
> >>
> >
> >Hi Jason, Tero
> >
> >This board is rather unusual for a Kirkwood. It has no Ethernet
> >interfaces. Is this correct?
>
> It seems like it really has an Gigabit Ethernet interface:
> http://www.clubic.com/disque-dur-memoire/nas/article-465814-1-zyxel-nsa-310.html
It's easy enough to add, we just need to know the phy_addr. Does anyone
have one to test?
thx,
Jason.
^ permalink raw reply
* [PATCH 4/4] drm/tilcdc: add support for LCD panels (v4)
From: Rob Clark @ 2013-01-24 14:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130124130856.GC31306@phenom.ffwll.local>
On Thu, Jan 24, 2013 at 7:08 AM, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, Jan 22, 2013 at 04:36:25PM -0600, Rob Clark wrote:
>> Add an output panel driver for LCD panels. Tested with LCD3 cape on
>> beaglebone.
>>
>> v1: original
>> v2: s/of_find_node_by_name()/of_get_child_by_name()/ from Pantelis
>> Antoniou
>> v3: add backlight support
>> v4: rebase to latest of video timing helpers
>>
>> Signed-off-by: Rob Clark <robdclark@gmail.com>
>
> So given that I'm utterly lacking clue about all things of (which seems to
> be where all the magic in this patch lies) I'm just gonna ask a few funny
> questions.
>
> [cut]
>
>> +static int panel_connector_get_modes(struct drm_connector *connector)
>> +{
>> + struct drm_device *dev = connector->dev;
>> + struct panel_connector *panel_connector = to_panel_connector(connector);
>> + struct display_timings *timings = panel_connector->mod->timings;
>> + int i;
>> +
>> + for (i = 0; i < timings->num_timings; i++) {
>> + struct drm_display_mode *mode = drm_mode_create(dev);
>> + struct videomode vm;
>> +
>> + if (videomode_from_timing(timings, &vm, i))
>> + break;
>> +
>> + drm_display_mode_from_videomode(&vm, mode);
>
> Why do we need to jump through the intermediate videomode thing here? Is
> that a deficiency of the of/videomode stuff?
there is a helper that cut through the intermediate videomode
structure, although it assumed you are doing that at the point where
you still have the 'struct device_node *' (in the probe code) which
didn't really fit well for how I had structured things. So I just
skipped it. I guess I could have gone straight to array of
drm_display_mode in the probe call, and then copied them here in
get_modes() but this just seemed a bit easier.
> [cut]
>
>> + ret |= of_property_read_u32(info_np, "ac-bias", &info->ac_bias);
>> + ret |= of_property_read_u32(info_np, "ac-bias-intrpt", &info->ac_bias_intrpt);
>> + ret |= of_property_read_u32(info_np, "dma-burst-sz", &info->dma_burst_sz);
>> + ret |= of_property_read_u32(info_np, "bpp", &info->bpp);
>> + ret |= of_property_read_u32(info_np, "fdd", &info->fdd);
>> + ret |= of_property_read_u32(info_np, "sync-edge", &info->sync_edge);
>> + ret |= of_property_read_u32(info_np, "sync-ctrl", &info->sync_ctrl);
>> + ret |= of_property_read_u32(info_np, "raster-order", &info->raster_order);
>> + ret |= of_property_read_u32(info_np, "fifo-th", &info->fifo_th);
>
> Shouldn't these values all be documented somewhere in the devictree docs?
> Or are they somewhat standardized?
Yeah, I guess I need to add DT docs.. I didn't realize this earlier.
BR,
-R
^ permalink raw reply
* [PATCH 1/2] misc/at24: Add at24c512b eeprom support
From: Linus Walleij @ 2013-01-24 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130123125001.GG16264@pengutronix.de>
On Wed, Jan 23, 2013 at 1:50 PM, Wolfram Sang <w.sang@pengutronix.de> wrote:
> On Wed, Jan 23, 2013 at 01:24:52PM +0100, Linus Walleij wrote:
>> On Wed, Jan 23, 2013 at 7:32 AM, Liu Ying <Ying.Liu@freescale.com> wrote:
>>
>> > This patch adds at24c512b eeprom support.
>> > The datasheet of at24c512b can be found at:
>> > http://www.alldatasheet.com/datasheet-pdf/pdf/
>> > 256958/ATMEL/AT24C512B-TH-B.html
>> >
>> > Signed-off-by: Liu Ying <Ying.Liu@freescale.com>
>>
>> Arnd Bergmann is the misc maintainer, route this by him.
>
> I usually take at24 patches via my I2C tree.
Oh I didn't mean he'd merge it, I meant route it by him as
in "let him have a look at it" :-)
Yours,
Linus Walleij
^ 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