Re: [PATCH] arch: cris: arch-v32: drivers: axisflashmap.c: Cleaning up inconsistent NULL checks
On Fri, May 23, 2014 at 12:00:09AM +0200, Rickard Strandqvist wrote: > Cleaning up inconsistent NULL checks. > There is otherwise a risk of a possible null pointer dereference. > > Was largely found by using a static code analysis program called cppcheck. ... and is a false positive. We can't enter this if-block unless ptable_head is set, which is only set if main_mtd is set. It might be useful to add it anyways, but there's a refactoring needed for the axisflashmaps, so I'll keep it for then. /^JN - Jesper Nilsson -- Jesper Nilsson -- jesper.nils...@axis.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/2] mmc: tegra: disable UHS modes
On 22 May 2014 17:55, Andrew Bresticker wrote:
> Program TEGRA_SDHCI_VENDOR_MISC_CTRL so that UHS modes aren't advertised
> in SDHCI_CAPABILITIES_1. While the Tegra SDHCI controller does support
> these modes, they require Tegra-specific tuning and calibration routines
> which the driver does not support yet.
>
> Signed-off-by: Andrew Bresticker
> Tested-by: Stephen Warren
> Acked-by: Stephen Warren
Thanks Andrew!
Signed-off-by: Ulf Hansson
Chris, can you pick this up?
Kind regards
Ulf Hansson
> ---
> Changes from v2:
> - rebased on mmc-next
> No changes from v1
> ---
> drivers/mmc/host/sdhci-tegra.c | 30 +++---
> 1 file changed, 23 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
> index 9852476..4375cd4 100644
> --- a/drivers/mmc/host/sdhci-tegra.c
> +++ b/drivers/mmc/host/sdhci-tegra.c
> @@ -32,11 +32,17 @@
>
> /* Tegra SDHOST controller vendor register definitions */
> #define SDHCI_TEGRA_VENDOR_MISC_CTRL 0x120
> +#define SDHCI_MISC_CTRL_ENABLE_SDR104 0x8
> +#define SDHCI_MISC_CTRL_ENABLE_SDR50 0x10
> #define SDHCI_MISC_CTRL_ENABLE_SDHCI_SPEC_300 0x20
> +#define SDHCI_MISC_CTRL_ENABLE_DDR50 0x200
>
> #define NVQUIRK_FORCE_SDHCI_SPEC_200 BIT(0)
> #define NVQUIRK_ENABLE_BLOCK_GAP_DET BIT(1)
> #define NVQUIRK_ENABLE_SDHCI_SPEC_300 BIT(2)
> +#define NVQUIRK_DISABLE_SDR50 BIT(3)
> +#define NVQUIRK_DISABLE_SDR104 BIT(4)
> +#define NVQUIRK_DISABLE_DDR50 BIT(5)
>
> struct sdhci_tegra_soc_data {
> const struct sdhci_pltfm_data *pdata;
> @@ -100,20 +106,25 @@ static void tegra_sdhci_reset(struct sdhci_host *host,
> u8 mask)
> struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> struct sdhci_tegra *tegra_host = pltfm_host->priv;
> const struct sdhci_tegra_soc_data *soc_data = tegra_host->soc_data;
> + u32 misc_ctrl;
>
> sdhci_reset(host, mask);
>
> if (!(mask & SDHCI_RESET_ALL))
> return;
>
> + misc_ctrl = sdhci_readw(host, SDHCI_TEGRA_VENDOR_MISC_CTRL);
> /* Erratum: Enable SDHCI spec v3.00 support */
> - if (soc_data->nvquirks & NVQUIRK_ENABLE_SDHCI_SPEC_300) {
> - u32 misc_ctrl;
> -
> - misc_ctrl = sdhci_readb(host, SDHCI_TEGRA_VENDOR_MISC_CTRL);
> + if (soc_data->nvquirks & NVQUIRK_ENABLE_SDHCI_SPEC_300)
> misc_ctrl |= SDHCI_MISC_CTRL_ENABLE_SDHCI_SPEC_300;
> - sdhci_writeb(host, misc_ctrl, SDHCI_TEGRA_VENDOR_MISC_CTRL);
> - }
> + /* Don't advertise UHS modes which aren't supported yet */
> + if (soc_data->nvquirks & NVQUIRK_DISABLE_SDR50)
> + misc_ctrl &= ~SDHCI_MISC_CTRL_ENABLE_SDR50;
> + if (soc_data->nvquirks & NVQUIRK_DISABLE_DDR50)
> + misc_ctrl &= ~SDHCI_MISC_CTRL_ENABLE_DDR50;
> + if (soc_data->nvquirks & NVQUIRK_DISABLE_SDR104)
> + misc_ctrl &= ~SDHCI_MISC_CTRL_ENABLE_SDR104;
> + sdhci_writew(host, misc_ctrl, SDHCI_TEGRA_VENDOR_MISC_CTRL);
> }
>
> static void tegra_sdhci_set_bus_width(struct sdhci_host *host, int bus_width)
> @@ -170,7 +181,9 @@ static const struct sdhci_pltfm_data sdhci_tegra30_pdata
> = {
>
> static struct sdhci_tegra_soc_data soc_data_tegra30 = {
> .pdata = &sdhci_tegra30_pdata,
> - .nvquirks = NVQUIRK_ENABLE_SDHCI_SPEC_300,
> + .nvquirks = NVQUIRK_ENABLE_SDHCI_SPEC_300 |
> + NVQUIRK_DISABLE_SDR50 |
> + NVQUIRK_DISABLE_SDR104,
> };
>
> static const struct sdhci_pltfm_data sdhci_tegra114_pdata = {
> @@ -184,6 +197,9 @@ static const struct sdhci_pltfm_data sdhci_tegra114_pdata
> = {
>
> static struct sdhci_tegra_soc_data soc_data_tegra114 = {
> .pdata = &sdhci_tegra114_pdata,
> + .nvquirks = NVQUIRK_DISABLE_SDR50 |
> + NVQUIRK_DISABLE_DDR50 |
> + NVQUIRK_DISABLE_SDR104,
> };
>
> static const struct of_device_id sdhci_tegra_dt_match[] = {
> --
> 1.9.1.423.g4596e3a
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/2] mmc: tegra: fix reporting of base clock frequency
On 22 May 2014 17:55, Andrew Bresticker wrote:
> Tegra SDHCI controllers, by default, report a base clock frequency
> of 208Mhz in SDHCI_CAPABILTIES which may or may not be equal to the
> actual base clock frequency. This is because the clock rate is
> configured by the clock controller, which is external to the SD/MMC
> controller. Since the SD/MMC controller has no knowledge of how this
> clock is configured, it will simply report the maximum frequency.
> While the reported value can be overridden by setting BASE_CLK_FREQ in
> VENDOR_CLOCK_CTRL on Tegra30 and later SoCs, just set CAP_CLOCK_BASE_BROKEN
> and supply sdhci_pltfm_clk_get_max_clock(), which simply does a
> clk_get_rate(), as the get_max_clock() callback.
>
> Signed-off-by: Andrew Bresticker
> Tested-by: Stephen Warren
> Acked-by: Stephen Warren
Thanks Andrew!
Signed-off-by: Ulf Hansson
Chris, can you pick this up?
Kind regards
Ulf Hansson
> ---
> Changes from v2:
> - rebased on mmc-next
> Changes from v1:
> - fixed up commit message per Stephen's suggestions
> ---
> drivers/mmc/host/sdhci-tegra.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/host/sdhci-tegra.c b/drivers/mmc/host/sdhci-tegra.c
> index 4375cd4..d93a063 100644
> --- a/drivers/mmc/host/sdhci-tegra.c
> +++ b/drivers/mmc/host/sdhci-tegra.c
> @@ -154,13 +154,15 @@ static const struct sdhci_ops tegra_sdhci_ops = {
> .set_bus_width = tegra_sdhci_set_bus_width,
> .reset = tegra_sdhci_reset,
> .set_uhs_signaling = sdhci_set_uhs_signaling,
> + .get_max_clock = sdhci_pltfm_clk_get_max_clock,
> };
>
> static const struct sdhci_pltfm_data sdhci_tegra20_pdata = {
> .quirks = SDHCI_QUIRK_BROKEN_TIMEOUT_VAL |
> SDHCI_QUIRK_SINGLE_POWER_WRITE |
> SDHCI_QUIRK_NO_HISPD_BIT |
> - SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC,
> + SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC |
> + SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN,
> .ops = &tegra_sdhci_ops,
> };
>
> @@ -175,7 +177,8 @@ static const struct sdhci_pltfm_data sdhci_tegra30_pdata
> = {
> SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
> SDHCI_QUIRK_SINGLE_POWER_WRITE |
> SDHCI_QUIRK_NO_HISPD_BIT |
> - SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC,
> + SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC |
> + SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN,
> .ops = &tegra_sdhci_ops,
> };
>
> @@ -191,7 +194,8 @@ static const struct sdhci_pltfm_data sdhci_tegra114_pdata
> = {
> SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK |
> SDHCI_QUIRK_SINGLE_POWER_WRITE |
> SDHCI_QUIRK_NO_HISPD_BIT |
> - SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC,
> + SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC |
> + SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN,
> .ops = &tegra_sdhci_ops,
> };
>
> --
> 1.9.1.423.g4596e3a
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tools: perf: util: session.c: Cleaning up inconsistent NULL checks
On Thu, May 22, 2014 at 11:58:36PM +0200, Rickard Strandqvist wrote:
> Cleaning up inconsistent NULL checks.
> There is otherwise a risk of a possible null pointer dereference.
>
> Was largely found by using a static code analysis program called cppcheck.
>
> Signed-off-by: Rickard Strandqvist
> ---
> tools/perf/util/session.c |4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
> index 55960f2..8defd80 100644
> --- a/tools/perf/util/session.c
> +++ b/tools/perf/util/session.c
> @@ -1625,13 +1625,15 @@ out_delete_map:
> void perf_session__fprintf_info(struct perf_session *session, FILE *fp,
> bool full)
> {
> - int fd = perf_data_file__fd(session->file);
> + int fd;
> struct stat st;
> int ret;
>
> if (session == NULL || fp == NULL)
> return;
>
> + fd = perf_data_file__fd(session->file);
> +
> ret = fstat(fd, &st);
> if (ret == -1)
> return;
> --
> 1.7.10.4
>
hi,
I merged same patch just a week ago or so ;-)
perf session: Fix possible null pointer dereference in session.c
commit c5765ece8a050836c6255e1276fc8e0e867078da
Author: Masanari Iida
Date: Thu May 15 02:13:38 2014 +0900
thanks,
jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: skbuff truesize incorrect.
David Miller writes: > From: Eric Dumazet > Date: Thu, 22 May 2014 14:03:21 -0700 > >> On Thu, 2014-05-22 at 13:58 -0700, Eric Dumazet wrote: >> >>> I would set rx_max (rx_urb_size) to SKB_MAX_HEAD(0) so that you do not >>> use high order allocations. >> >> Correction, that would need SKB_MAX_HEAD(NET_SKB_PAD + NET_IP_ALIGN), >> because drivers/net/usb/usbnet.c calls __netdev_alloc_skb_ip_align(). > > I seem to recall that this driver has a lot of strange buffering > restrictions and that Bjorn Mork was talking a lot about this > recently. Yes, I have been following this discussion with great interest, learning a lot. But although the problem is the same, I believe the driver in question isn't the one I have been looking at recently. The posted code snippet was from the NCM gadget driver (drivers/usb/gadget/f_ncm.c), isn't that right Jim? That driver implements the same protocol with the same inherent issues, but for the device side. The implementations are independent for historical reasons. This happened before I started looking at these things so I don't know exactly why. In an ideal world they should have shared pretty much everything except setup. > Bjorn people are getting really burnt because the driver ends up > having a skb->truesize of 32K for the buffers it allocates on receive > and this chokes up TCP and SCTP because the socket memory limits > are hitting earlier than they should. > > We've just in the past few postings been discussing whether the just > copy every packet into a more appropriately sized buffer, and it isn't > clear if that's a good idea of the data rates handled here. Yes, judging by this discussion I guess we should unconditionally copy instead of cloning in these drivers. We'll always have bad payload/truesize ratio for cloned skbs, often less than 1/10 even for max size payload. Actually, I thought we already did copy in the host cdc_ncm driver. But I was wrong. I was thinking of the cdc_mbim driver (which is different enough to have its own implementation of this part of the rx code). The cdc_ncm driver is cloning and the cdc_mbim driver is copying. So we're not even consistent... I'll create and test a patch for the cdc_ncm host driver unless someone else wants to do that. I haven't really played with the gadget driver before, so I'd prefer if someone knowing it (Jim maybe?) could take care of it. If not, then I can always make an attempt using dummy_hcd to test it. BTW, wrt the data rates: These drivers are USB class drivers and we should really think of *all* possible rates, even future ones. This is not limited to 480 Mbps USB2. AFAICS, there isn't anything preventing the gadget driver from being used with e.g. a USB3380 controller to create a 5 Gbps NCM device. I'm sure the future will bring us even faster USB devices. The drivers will be the same. Which is sort of beautiful and scaring at the same time :-) But I assume the bad payload/truesize ratio is the most important factor here, so we should still copy? Bjørn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Staging: Media: sn9c102: Fixed a pointer declaration coding style issue
On Thu, May 22, 2014 at 04:11:38PM -0700, Chaitanya wrote: > Fixed the ERROR thrown off by checkpatch.pl. > Put the error message here, or say what it was. > Signed-off-by: Chaitanya Hazarey Could you change your email client so it has your last in the From: header? This patch doesn't apply. Read this: https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/tree/Documentation/email-clients.txt regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] drm/nouveau: disable caching for VRAM BOs on ARM
On Mon, May 19, 2014 at 7:16 PM, Lucas Stach wrote: > Am Montag, den 19.05.2014, 19:06 +0900 schrieb Alexandre Courbot: >> On 05/19/2014 06:57 PM, Lucas Stach wrote: >> > Am Montag, den 19.05.2014, 18:46 +0900 schrieb Alexandre Courbot: >> >> This patch is not meant to be merged, but rather to try and understand >> >> why this is needed and what a more suitable solution could be. >> >> >> >> Allowing BOs to be write-cached results in the following happening when >> >> trying to run any program on Tegra/GK20A: >> >> >> >> Unhandled fault: external abort on non-linefetch (0x1008) at 0xf0036010 >> >> ... >> >> (nouveau_bo_rd32) from [] (nouveau_fence_update+0x5c/0x80) >> >> (nouveau_fence_update) from [] (nouveau_fence_done+0x1c/0x38) >> >> (nouveau_fence_done) from [] (ttm_bo_wait+0xec/0x168) >> >> (ttm_bo_wait) from [] (nouveau_gem_ioctl_cpu_prep+0x44/0x100) >> >> (nouveau_gem_ioctl_cpu_prep) from [] (drm_ioctl+0x1d8/0x4f4) >> >> (drm_ioctl) from [] (nouveau_drm_ioctl+0x54/0x80) >> >> (nouveau_drm_ioctl) from [] (do_vfs_ioctl+0x3dc/0x5a0) >> >> (do_vfs_ioctl) from [] (SyS_ioctl+0x34/0x5c) >> >> (SyS_ioctl) from [] (ret_fast_syscall+0x0/0x30 >> >> >> >> The offending nouveau_bo_rd32 is done over an IO-mapped BO, e.g. a BO >> >> mapped through the BAR. >> >> >> > Um wait, this memory is behind an already mapped bar? I think ioremap on >> > ARM defaults to uncached mappings, so if you want to access the memory >> > behind this bar as WC you need to map the BAR as a whole as WC by using >> > ioremap_wc. >> >> Tried mapping the BAR using ioremap_wc(), but to no avail. On the other >> hand, could it be that VRAM BOs end up creating a mapping over an >> already-mapped region? I seem to remember that ARM might not like it... > > Multiple mapping are generally allowed, as long as they have the same > caching state. It's conflicting mappings (uncached vs cached, or cached > vs wc), that are documented to yield undefined results. Sorry about the confusion. The BAR is *not* mapped to the kernel yet (it is BAR1, there is no BAR3 on GK20A) and an ioremap_*() is performed in ttm_bo_ioremap() to make the part of the BAR where the buffer is mapped visible. It seems that doing an ioremap_wc() on the BAR area on Tegra is what leads to these errors. ioremap() or ioremap_nocache() (which are in effect the same on ARM) do not cause this issue. The best way to solve this issue would be to not use the BAR at all since the memory behind these objects can be directly accessed by the CPU. As such it would better be mapped using ttm_bo_kmap_ttm() instead. But right now this is clearly not how nouveau_bo.c is written and it does not look like this can easily be done. :/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/3] mfd: AXP22x: add support for APX221 PMIC
Hello Lee On 20/05/2014 09:48, Lee Jones wrote: > This patch introduces preliminary support for the X-Powers AXP221 PMIC. > The AXP221 is typically used on boards using Allwinner's A31 SoC. > > At the moment, this driver only exposes regulator devices, but other > subdevices. > > Signed-off-by: Boris BREZILLON > --- > drivers/mfd/Kconfig| 12 +++ > drivers/mfd/Makefile | 1 + > drivers/mfd/axp22x.c | 237 > + > include/linux/mfd/axp22x.h | 149 > 4 files changed, 399 insertions(+) > create mode 100644 drivers/mfd/axp22x.c > create mode 100644 include/linux/mfd/axp22x.h Not a chance. Fa, too much common code with axp20x.c - please merge into one file. >>> This was one of the questions I asked in my cover letter (could you take >>> a look at it and tell me what's your prefered solution ?) ;-). >>> >>> I first tried to reuse the axp20x drivers, but ended up copying almost >>> all definitions, hence I decided to first do a different driver and ask >>> for advices. >> I've just taken a good look at this (I'm planning on doing an axp152 driver >> myself), and it seems that using a single mfd driver for the 20x and 221 >> should >> be quite feasible: >> >> - axp20x.h would get some new register defines for registers which are >> different (or unique) to the 221 prefixed with aXP221 >> - An axp20x_writeable_ranges would need >> to be extended with a third range going from AXP221_BAT_CAP1 (0xe0) >> to AXP221_BAT_LOW_THRESH (0xe6) >> - axp20x_writeable_table would get .n_yes_ranges set to 2, and a new >> apx22x_writeable_table would be introduced with n_yes_ranges set to 3. >> - add a new axp221_supplies array >> - add a new axp221_cells array >> - and finally use the proper structs in axp20x_i2c_probe depending on the >> type >> >> Note that this means sharing ie the interrupt table, which is ok since they >> are the same, except that the 221 has a couple of interrupts missing, but >> the ones which are shared are all at the same place. > Exactly. As .probe() is identical, you only require some device > matching and some extra structs where the data actually differs > between devices. > I think you've applied this patch on your for-next tree by mistake. As stated above, this driver should be merged with the axp20x one. Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/14] Add Qualcomm SD Card Controller support
Hi Ulf, I like to get this patches for v3.16, any chance of considering these patches to v3.16 ? --srini On 15/05/14 10:34, srinivas.kandaga...@linaro.org wrote: From: Srinivas Kandagatla Thankyou everyone for reviewing both RFC and v1 patches. This patch series adds Qualcomm SD Card Controller support in pl180 mmci driver. QCom SDCC is basically a pl180, but bit more customized, some of the register layouts and offsets are different to the ones mentioned in pl180 datasheet. The plan is to totally remove the standalone SDCC driver drivers/mmc/host/msm_sdcc.* and start using generic mmci driver for all Qualcomm parts, as we get chance to test on other Qcom boards. To start using the existing mmci driver, a fake amba id for Qualcomm is added in patches: mmc: mmci: Add Qualcomm Id to amba id table. Second change is, adding a 3 clock cycle delay for register writes on QCOM SDCC registers, which is done in patches: mmc: mmci: Add register read/write wrappers. mmc: mmci: Qcomm: Add 3 clock cycle delay after register write Third change is to accommodate CLK, DATCTRL and MMCICLK register layout changes in Qcom SDCC and provide more flexibity in driver to specify these changes via variant datastructure. Which are done in patches: mmc: mmci: Add Qcom datactrl register variant mmc: mmci: add ddrmode mask to variant data mmc: mmci: add 8bit bus support in variant data mmc: mmci: add edge support to data and command out in variant data. mmc: mmci: add Qcom specifics of clk and datactrl registers. mmc: mmci: Add support to data commands via variant structure. mmc: mmci: add support for fbclk to latch data and cmd. mmc: mmci: add qcom specific clk control Fourth major change was to add qcom specfic pio read function, the need for this is because the way MCIFIFOCNT register behaved in QCOM SDCC is very different to the one in pl180. This change is done in patch: mmc: mmci: Add Qcom specific pio_read function. Last some Qcom unrelated changes/cleanup to driver are done in patches: mmc: mmci: use NSEC_PER_SEC macro mmc: mmci: convert register bits to use BIT() macro. This patches are tested in PIO mode on IFC8064 board with both eMMC and external SD card. I would like to get this support in v3.16. Changes from v1: - moved most of the SOC specifics to variant parameters as suggested by Linus W. - renamed registers as suggested by Linus W. - Added comments in the code as suggested by Linus W. - moved out AMBA ID addition patch from this series. - rebased the patches to git://git.linaro.org/people/ulf.hansson/mmc.git next as suggested by Ulf H. Changes from RFC: - moved out clk setup out of spinlock as pointed by Stephen B. Thanks, srini Srinivas Kandagatla (14): mmc: mmci: use NSEC_PER_SEC macro mmc: mmci: convert register bits to use BIT() macro. mmc: mmci: Add Qualcomm Id to amba id table mmc: mmci: Add Qcom datactrl register variant mmc: mmci: Add register read/write wrappers. mmc: mmci: Qcomm: Add 3 clock cycle delay after register write mmc: mmci: add ddrmode mask to variant data mmc: mmci: add 8bit bus support in variant data mmc: mmci: add edge support to data and command out in variant data. mmc: mmci: add Qcom specifics of clk and datactrl registers. mmc: mmci: Add support to data commands via variant structure. mmc: mmci: add support for fbclk to latch data and cmd. mmc: mmci: add qcom specific clk control mmc: mmci: Add Qcom specific pio_read function. drivers/mmc/host/mmci.c | 245 drivers/mmc/host/mmci.h | 232 + 2 files changed, 311 insertions(+), 166 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ASoC: Intel: avoid format string leak to thread name
On 05/22/2014 09:43 PM, Kees Cook wrote:
This makes sure a format string can never get processed into the worker
thread name from the device name.
Signed-off-by: Kees Cook
---
sound/soc/intel/sst-baytrail-ipc.c |2 +-
sound/soc/intel/sst-haswell-ipc.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/intel/sst-baytrail-ipc.c
b/sound/soc/intel/sst-baytrail-ipc.c
index 0d31dbbf4806..1b25bf168beb 100644
--- a/sound/soc/intel/sst-baytrail-ipc.c
+++ b/sound/soc/intel/sst-baytrail-ipc.c
@@ -809,7 +809,7 @@ int sst_byt_dsp_init(struct device *dev, struct sst_pdata
*pdata)
/* start the IPC message thread */
init_kthread_worker(&byt->kworker);
byt->tx_thread = kthread_run(kthread_worker_fn,
-&byt->kworker,
+&byt->kworker, "%s",
dev_name(byt->dev));
if (IS_ERR(byt->tx_thread)) {
err = PTR_ERR(byt->tx_thread);
diff --git a/sound/soc/intel/sst-haswell-ipc.c
b/sound/soc/intel/sst-haswell-ipc.c
index e7996b39a484..a8fd60c67341 100644
--- a/sound/soc/intel/sst-haswell-ipc.c
+++ b/sound/soc/intel/sst-haswell-ipc.c
@@ -1735,7 +1735,7 @@ int sst_hsw_dsp_init(struct device *dev, struct sst_pdata
*pdata)
/* start the IPC message thread */
init_kthread_worker(&hsw->kworker);
hsw->tx_thread = kthread_run(kthread_worker_fn,
- &hsw->kworker,
+ &hsw->kworker, "%s",
dev_name(hsw->dev));
if (IS_ERR(hsw->tx_thread)) {
ret = PTR_ERR(hsw->tx_thread);
This is not very fatal as name comes from sound/soc/intel/sst-acpi.c so
only developer can hit this but to be on safe side:
Acked-by: Jarkko Nikula
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the tip tree
Hi all,
After merging the tip tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
In file included from arch/arm/include/asm/outercache.h:24:0,
from arch/arm/include/asm/barrier.h:5,
from arch/arm/include/asm/bitops.h:28,
from include/linux/bitops.h:33,
from include/linux/kernel.h:10,
from include/asm-generic/bug.h:13,
from arch/arm/include/asm/bug.h:61,
from arch/arm/include/asm/div64.h:63,
from include/linux/math64.h:5,
from include/linux/jiffies.h:4,
from init/calibrate.c:7:
include/linux/bug.h:91:47: warning: 'struct bug_entry' declared inside
parameter list [enabled by default]
include/linux/bug.h:91:47: warning: its scope is only this definition or
declaration, which is probably not what you want [enabled by default]
include/linux/bug.h: In function 'is_warning_bug':
include/linux/bug.h:93:12: error: dereferencing pointer to incomplete type
... and many, many more ...
Probably caused by commit 030d0178bdbd ("arch,arm: Convert
smp_mb__*()") which added an include of asm/barrier.h to
arch/arm/include/asm/bitops.h. This has interacted with commit
59a3bc6d3343 ("ARM: outer cache: add WARN_ON() to outer_disable()")
from the arm tree, which adds an include of linux/bug.h to
arch/arm/include/asm/outercache.h.
I added the below merge fix patch. Russell, this should be applied to
your tree directly.
From: Stephen Rothwell
Date: Fri, 23 May 2014 17:10:12 +1000
Subject: [PATCH] ARM: outer cache: no need for bug.h in outercache.h
This fixes a cricular include dependency when combined with commits from
the tip tree.
Signed-off-by: Stephen Rothwell
---
arch/arm/include/asm/outercache.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/include/asm/outercache.h
b/arch/arm/include/asm/outercache.h
index eaa8a28c6871..891a56b35bcf 100644
--- a/arch/arm/include/asm/outercache.h
+++ b/arch/arm/include/asm/outercache.h
@@ -21,7 +21,6 @@
#ifndef __ASM_OUTERCACHE_H
#define __ASM_OUTERCACHE_H
-#include
#include
struct outer_cache_fns {
--
2.0.0.rc4
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
signature.asc
Description: PGP signature
Re: [PATCH 2/5] ARM: tegra: of: add GK20A device tree binding
On Tue, May 20, 2014 at 6:14 AM, Stephen Warren wrote:
> On 05/19/2014 03:24 AM, Alexandre Courbot wrote:
>> Add the device tree binding documentation for the GK20A GPU used in
>> Tegra K1 SoCs.
>
> A few minor nits, but otherwise,
> Acked-by: Stephen Warren
>
>> diff --git a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
>> b/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
>
>> +Required properties:
>> +- compatible: "nvidia,-"
>> + Currently recognized values:
>> + - nvidia,tegra124-gk20a
>> +- reg: Physical base address and length of the controller's registers.
>> + Must contain two entries:
>> + - first entry for bar0
>> + - second entry for bar1
>> +- interrupts: The interrupt outputs from the controller.
>
> To be consistent with the clocks and resets properties, it'd be nice to
> reword that as:
>
> interrupts: Must contain an entry for each entry in interrupt-names.
>
>> +- interrupt-names: Must include the following entries:
>
> ... and add the following here:
>
> See ../interrupt-controller/interrupts.txt
>
>> +/ {
>
> No need to wrap a root node around this in the example.
>
>> + gpu@0,5700 {
> ...
>> + };
>> +
>
> Extra blank line here.
>
>> +};
>
All fixed and acked-by added to the commit log.
Thanks,
Alex.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: Neaten clk_summary output
Hi Mike,
On Tue, May 13, 2014 at 2:17 AM, Mike Turquette wrote:
> Quoting Geert Uytterhoeven (2014-03-25 04:16:24)
>> From: Geert Uytterhoeven
>>
>> - Limit ruler to 80 characters (was: 81),
>> - Widen rate column by 1 for nicer spacing,
>> - Right-align numbers and their column headers,
>> - Move a newline to reduce the number of seq_printf() calls,
>> - Use set_puts() for fixed strings.
>> Signed-off-by: Geert Uytterhoeven
>
> Thanks for the fix. Taken into clk-next.
I don't see it in clk-next, though?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND] mmc: dove: fix missing MACH_DOVE dependency
On Thu, May 22, 2014 at 2:09 AM, Ulf Hansson wrote: > On 19 May 2014 20:02, Sebastian Hesselbarth > wrote: >> DT-enabled Dove moved over from ARCH_DOVE in mach-dove to MACH_DOVE in >> mach-mvebu. As non-DT ARCH_DOVE will stay to rot for a while, add a new >> DT-only MACH_DOVE Kconfig. This slipped through the cracks and now is >> a fix to allow to build Dove's SDHCI driver for mach-mvebu on v3.15-rc. >> >> Signed-off-by: Sebastian Hesselbarth >> Acked-by: Jason Cooper > > Thanks! Picked up for the PR I send to Chris. Ulf, you might consider adding your tree to linux-next if this is going to be a common work flow for you guys. It's partially up to Chris though, if he's OK with patches going into your branch more or less being guaranteed to make it into his as well. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] pinctrl: baytrail: Add back Baytrail-T ACPI ID
On Thu, May 22, 2014 at 11:50:00PM +0200, Linus Walleij wrote: > On Thu, May 15, 2014 at 5:28 PM, Mika Westerberg > wrote: > > > From: Jin Yao > > > > Now that the x86 dynamic IRQ allocation problem has been resolved with > > commmit 62a08ae2a576 (genirq: x86: Ensure that dynamic irq allocation does > > not conflict), we can add back Baytrail-T ACPI ID to the pinctrl driver. > > > > This makes the driver to work on Asus T100 where it is needed for several > > things like ACPI GPIO events and SD card detection. > > > > References: https://bugzilla.kernel.org/show_bug.cgi?id=68291 > > Signed-off-by: Jin Yao > > Signed-off-by: Mika Westerberg > > Patch applied with Rafael's ACK. > > Applying this and 2/2 to v3.16 though, protest if there is a problem with > this. v3.16 is fine. Thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the pwm tree with the leds tree
On Thu, May 22, 2014 at 07:24:23PM +1000, Stephen Rothwell wrote:
> Hi Thierry,
>
> Today's linux-next merge of the pwm tree got a conflict in
> drivers/leds/leds-pwm.c between commit 5f7b03dc2ab5 ("leds: leds-pwm:
> provide a common function to setup a single led-pwm device") from the
> leds tree and commit 81225bed3273 ("leds: leds-pwm: retrieve configured
> PWM period") from the pwm tree.
>
> I fixed it up (I think - see below) and can carry the fix as necessary
> (no action is required).
The resolution below looks good to me. Thanks!
Alexandre, Bryan, as far as I can tell there are no dependencies between
this patch and the rest of the series that Alexandre sent, so perhaps it
would be a better idea to take this particular patch via Bryan's leds
tree?
Then again the resolution looks like something that Linus can reasonably
handle, so maybe things are fine as-is.
Thierry
>
> --
> Cheers,
> Stephen Rothwells...@canb.auug.org.au
>
> diff --cc drivers/leds/leds-pwm.c
> index f5cf1b0f2748,aa770ec1e892..
> --- a/drivers/leds/leds-pwm.c
> +++ b/drivers/leds/leds-pwm.c
> @@@ -96,75 -92,55 +96,75 @@@ static void led_pwm_cleanup(struct led_
> }
> }
>
> -static int led_pwm_create_of(struct platform_device *pdev,
> - struct led_pwm_priv *priv)
> +static int led_pwm_add(struct device *dev, struct led_pwm_priv *priv,
> + struct led_pwm *led, struct device_node *child)
> {
> -struct device_node *child;
> +struct led_pwm_data *led_data = &priv->leds[priv->num_leds];
> int ret;
>
> -for_each_child_of_node(pdev->dev.of_node, child) {
> -struct led_pwm_data *led_dat = &priv->leds[priv->num_leds];
> +led_data->active_low = led->active_low;
> - led_data->period = led->pwm_period_ns;
> +led_data->cdev.name = led->name;
> +led_data->cdev.default_trigger = led->default_trigger;
> +led_data->cdev.brightness_set = led_pwm_set;
> +led_data->cdev.brightness = LED_OFF;
> +led_data->cdev.max_brightness = led->max_brightness;
> +led_data->cdev.flags = LED_CORE_SUSPENDRESUME;
>
> -led_dat->cdev.name = of_get_property(child, "label",
> - NULL) ? : child->name;
> +if (child)
> +led_data->pwm = devm_of_pwm_get(dev, child, NULL);
> +else
> +led_data->pwm = devm_pwm_get(dev, led->name);
> +if (IS_ERR(led_data->pwm)) {
> +ret = PTR_ERR(led_data->pwm);
> +dev_err(dev, "unable to request PWM for %s: %d\n",
> +led->name, ret);
> +return ret;
> +}
>
> - if (child)
> - led_data->period = pwm_get_period(led_data->pwm);
> -led_dat->pwm = devm_of_pwm_get(&pdev->dev, child, NULL);
> -if (IS_ERR(led_dat->pwm)) {
> -dev_err(&pdev->dev, "unable to request PWM for %s\n",
> -led_dat->cdev.name);
> -ret = PTR_ERR(led_dat->pwm);
> -goto err;
> -}
> -/* Get the period from PWM core when n*/
> -led_dat->period = pwm_get_period(led_dat->pwm);
> ++led_data->period = pwm_get_period(led_data->pwm);
> ++if (!led_data->period && (led->pwm_period_ns > 0))
> ++led_data->period = led->pwm_period_ns;
>
> -led_dat->cdev.default_trigger = of_get_property(child,
> -"linux,default-trigger", NULL);
> -of_property_read_u32(child, "max-brightness",
> - &led_dat->cdev.max_brightness);
> +led_data->can_sleep = pwm_can_sleep(led_data->pwm);
> +if (led_data->can_sleep)
> +INIT_WORK(&led_data->work, led_pwm_work);
> +
> +ret = led_classdev_register(dev, &led_data->cdev);
> +if (ret == 0) {
> +priv->num_leds++;
> +} else {
> +dev_err(dev, "failed to register PWM led for %s: %d\n",
> +led->name, ret);
> +}
> +
> +return ret;
> +}
> +
> +static int led_pwm_create_of(struct device *dev, struct led_pwm_priv *priv)
> +{
> +struct device_node *child;
> +struct led_pwm led;
> +int ret = 0;
> +
> +memset(&led, 0, sizeof(led));
>
> -led_dat->cdev.brightness_set = led_pwm_set;
> -led_dat->cdev.brightness = LED_OFF;
> -led_dat->cdev.flags |= LED_CORE_SUSPENDRESUME;
> +for_each_child_of_node(dev->of_node, child) {
> +led.name = of_get_property(child, "label", NULL) ? :
> + child->name;
>
> -led_dat->can_sleep = pwm_can_sleep(led_dat->pwm);
> -if (led_dat->can_sleep)
> -INIT_WORK(&led_dat->work, led_pwm_work);
> +led.default_trigger = of_get_property(child,
> +
Re: powerpc: remove checks for CONFIG_BOOK3E_MMU_TLB_STATS
Scott, On Thu, 2014-05-22 at 17:37 -0500, Scott Wood wrote: > /home/scott/fsl/git/linux/upstream/arch/powerpc/mm/tlb_low_64e.S: Assembler > messages: > /home/scott/fsl/git/linux/upstream/arch/powerpc/mm/tlb_low_64e.S:89: Error: > unrecognized opcode: `tlb_miss_prolog_stats' > /home/scott/fsl/git/linux/upstream/arch/powerpc/mm/tlb_low_64e.S:238: Error: > unrecognized opcode: `tlb_miss_prolog_stats' > /home/scott/fsl/git/linux/upstream/arch/powerpc/mm/tlb_low_64e.S:269: Error: > unrecognized opcode: `tlb_miss_prolog_stats' > /home/scott/fsl/git/linux/upstream/arch/powerpc/mm/tlb_low_64e.S:281: Error: > unrecognized opcode: `tlb_miss_prolog_stats' > /home/scott/fsl/git/linux/upstream/arch/powerpc/mm/tlb_low_64e.S:441: Error: > unrecognized opcode: `tlb_miss_prolog_stats' > /home/scott/fsl/git/linux/upstream/arch/powerpc/mm/tlb_low_64e.S:510: Error: > unrecognized opcode: `tlb_miss_prolog_stats' > /home/scott/fsl/git/linux/upstream/arch/powerpc/mm/tlb_low_64e.S:881: Error: > unrecognized opcode: `tlb_miss_prolog_stats' > /home/scott/fsl/git/linux/upstream/arch/powerpc/mm/tlb_low_64e.S:918: Error: > unrecognized opcode: `tlb_miss_prolog_stats' Thanks for testing! That's a bit surprising. The patch is intended to be a non event. Ie, it only removes what the preprocessor would have removed anyway. Unless I botched it, of course. What exactly did you test there? Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/8] mmc: sdhci-st: Intial support for ST SDHCI controller
On 22 May 2014 17:18, Peter Griffin wrote:
> This platform driver adds initial support for the SDHCI host controller
> found on STMicroelectronics SoCs.
>
> It has been tested on STiH41x b2020 platforms currently.
>
> Signed-off-by: Peter Griffin
> Signed-off-by: Giuseppe Cavallaro
> ---
> drivers/mmc/host/Kconfig| 12 +++
> drivers/mmc/host/Makefile | 1 +
> drivers/mmc/host/sdhci-st.c | 244
>
> 3 files changed, 257 insertions(+)
> create mode 100644 drivers/mmc/host/sdhci-st.c
>
> diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> index 8aaf8c1..b62c40d 100644
> --- a/drivers/mmc/host/Kconfig
> +++ b/drivers/mmc/host/Kconfig
> @@ -283,6 +283,18 @@ config MMC_SDHCI_BCM2835
>
> If unsure, say N.
>
> +config MMC_SDHCI_ST
> + tristate "SDHCI support on STMicroelectronics SoC"
> + depends on ARCH_STI
> + depends on MMC_SDHCI_PLTFM
> + select MMC_SDHCI_IO_ACCESSORS
> + help
> + This selects the Secure Digital Host Controller Interface in
> + STMicroelectronics SoCs.
> +
> + If you have a controller with this interface, say Y or M here.
> + If unsure, say N.
> +
> config MMC_OMAP
> tristate "TI OMAP Multimedia Card Interface support"
> depends on ARCH_OMAP
> diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
> index 0c8aa5e..6e0acf7 100644
> --- a/drivers/mmc/host/Makefile
> +++ b/drivers/mmc/host/Makefile
> @@ -64,6 +64,7 @@ obj-$(CONFIG_MMC_SDHCI_OF_HLWD) +=
> sdhci-of-hlwd.o
> obj-$(CONFIG_MMC_SDHCI_BCM_KONA) += sdhci-bcm-kona.o
> obj-$(CONFIG_MMC_SDHCI_BCM2835)+= sdhci-bcm2835.o
> obj-$(CONFIG_MMC_SDHCI_MSM)+= sdhci-msm.o
> +obj-$(CONFIG_MMC_SDHCI_ST) += sdhci-st.o
>
> ifeq ($(CONFIG_CB710_DEBUG),y)
> CFLAGS-cb710-mmc+= -DDEBUG
> diff --git a/drivers/mmc/host/sdhci-st.c b/drivers/mmc/host/sdhci-st.c
> new file mode 100644
> index 000..1790fa7
> --- /dev/null
> +++ b/drivers/mmc/host/sdhci-st.c
> @@ -0,0 +1,244 @@
> +/*
> + * Support for SDHCI on STMicroelectronics SoCs
> + *
> + * Copyright (C) 2014 STMicroelectronics Ltd
> + * Author: Giuseppe Cavallaro
> + *
> + * Based on sdhci-cns3xxx.c
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "sdhci-pltfm.h"
> +
> +struct st_mmc_platform_data {
> + struct reset_control *rstc;
> +};
> +
> +static int sdhci_st_8bit_width(struct sdhci_host *host, int width)
> +{
> + u8 ctrl;
> +
> + ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL);
> +
> + switch (width) {
> + case MMC_BUS_WIDTH_8:
> + ctrl |= SDHCI_CTRL_8BITBUS;
> + ctrl &= ~SDHCI_CTRL_4BITBUS;
> + break;
> + case MMC_BUS_WIDTH_4:
> + ctrl |= SDHCI_CTRL_4BITBUS;
> + ctrl &= ~SDHCI_CTRL_8BITBUS;
> + break;
> + default:
> + ctrl &= ~(SDHCI_CTRL_8BITBUS | SDHCI_CTRL_4BITBUS);
> + break;
> + }
> +
> + sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL);
> +
> + return 0;
> +}
> +
> +static unsigned int sdhci_st_get_max_clk(struct sdhci_host *host)
> +{
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> +
> + return clk_get_rate(pltfm_host->clk);
> +}
There are sdhci library function for the above:
sdhci_pltfm_clk_get_max_clock()
> +
> +static u32 sdhci_st_readl(struct sdhci_host *host, int reg)
> +{
> + u32 ret;
> +
> + switch (reg) {
> + case SDHCI_CAPABILITIES:
> + ret = readl(host->ioaddr + reg);
> + /* Support 3.3V and 1.8V */
> + ret &= ~SDHCI_CAN_VDD_300;
> + break;
> + default:
> + ret = readl(host->ioaddr + reg);
> + }
> + return ret;
> +}
> +
> +static const struct sdhci_ops sdhci_st_ops = {
> + .get_max_clock = sdhci_st_get_max_clk,
> + .platform_bus_width = sdhci_st_8bit_width,
> + .read_l = sdhci_st_readl,
> +};
> +
> +static const struct sdhci_pltfm_data sdhci_st_pdata = {
> + .ops = &sdhci_st_ops,
> + .quirks = SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC |
> + SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN,
> +};
> +
> +
> +static int sdhci_st_probe(struct platform_device *pdev)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + struct sdhci_host *host;
> + struct st_mmc_platform_
Re: [PATCH v2] gpio: make of_get_named_gpiod_flags() private
On Fri, May 23, 2014 at 5:34 AM, Alexandre Courbot wrote: > Looks like the world did not break this time. However I noticed that > the commit in your tree (and -next) included the changes since v1 in > its log. Is it intended? Yeah I copy that into the changelog sometimes. If I need that info it's easier to have it in the commit message than looking up the mail. Grant had this preference too. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] drm/ttm: introduce dma cache sync helpers
On Fri, May 23, 2014 at 02:49:40PM +0900, Alexandre Courbot wrote: > On Mon, May 19, 2014 at 5:33 PM, Thierry Reding > wrote: > > On Mon, May 19, 2014 at 04:10:56PM +0900, Alexandre Courbot wrote: > >> From: Lucas Stach > >> > >> On arches with non-coherent PCI, > > > > I guess since this applies to gk20a > > > >> we need to flush caches ourselfes at > > > > "ourselves". Or perhaps even reword to something like: "..., caches need > > to be flushed and invalidated explicitly", since dma_sync_for_cpu() does > > invalidate rather than flush. > > Rephrased as "On arches for which access to GPU memory is non-coherent, caches > need to be flushed and invalidated explicitly at the appropriate places." Nit: s/arches/architectures/ Thierry pgpVdWAgPBKxk.pgp Description: PGP signature
Re: [PATCH RESEND] mmc: dove: fix missing MACH_DOVE dependency
On 23 May 2014 09:16, Olof Johansson wrote: > On Thu, May 22, 2014 at 2:09 AM, Ulf Hansson wrote: >> On 19 May 2014 20:02, Sebastian Hesselbarth >> wrote: >>> DT-enabled Dove moved over from ARCH_DOVE in mach-dove to MACH_DOVE in >>> mach-mvebu. As non-DT ARCH_DOVE will stay to rot for a while, add a new >>> DT-only MACH_DOVE Kconfig. This slipped through the cracks and now is >>> a fix to allow to build Dove's SDHCI driver for mach-mvebu on v3.15-rc. >>> >>> Signed-off-by: Sebastian Hesselbarth >>> Acked-by: Jason Cooper >> >> Thanks! Picked up for the PR I send to Chris. > > Ulf, you might consider adding your tree to linux-next if this is > going to be a common work flow for you guys. That's done already. :-) There are patches which makes this visible in the MAINTAINERS as well, queued for 3.16. git://git.linaro.org/people/ulf.hansson/mmc.git next Though due to merge conflicts, during this release cycle, I didn't want to queue any patches besides for the mmci host driver. > > It's partially up to Chris though, if he's OK with patches going into > your branch more or less being guaranteed to make it into his as well. > Yes, we need to figure out a good work flow when using two separate trees. Thanks for bringing this up! Kind regards Ulf Hansson -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers: staging: removing never #def'd BP_PROC_SUPPORT
On Mon, Apr 07, 2014 at 01:00:57PM +0200, Jan Moskyto Matejka wrote: > BP_PROC_SUPPORT was never defined so removing all the #ifdef'd code > including the bp_proc_create() function. > > Signed-off-by: Jan Moskyto Matejka > --- > drivers/staging/silicom/bpctl_mod.c | 39 > - > 1 file changed, 39 deletions(-) Someone sent this same patch before you did, sorry :( greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/14] Add Qualcomm SD Card Controller support
On 23 May 2014 09:13, Srinivas Kandagatla wrote: > Hi Ulf, > I like to get this patches for v3.16, any chance of considering these > patches to v3.16 ? I promise to have them properly reviewed early next week, sorry for taking so long. Let's see where this leads us. It seems like you had some CRC issues during read/write? Did you manage to resolve that issue? Kind regards Ulf Hansson -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] DWC2: intializes the spin_lock earlier in the probe
My mistake. It actually comes not from the mainline but from the altera tree.
Sorry for the noise
2014-05-22 20:48 GMT+02:00 Paul Zimmerman :
>
>> From: Jean-Jacques Hiblot [mailto:jjhib...@traphandler.com]
>> Sent: Thursday, May 22, 2014 5:10 AM
>>
>> The spinlock hsotg->lock is intialized at the end of the probe. However it
>> may be used from within dwc2_hcd_init(). This patch moves the
>> initialization before the call to dwc2_hcd_init(). This make the locking
>> correctness validator happy.
>>
>> Signed-off-by: Jean-Jacques Hiblot
>> ---
>> drivers/usb/dwc2/platform.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/dwc2/platform.c b/drivers/usb/dwc2/platform.c
>> index 37a8ab0..55fb30d 100644
>> --- a/drivers/usb/dwc2/platform.c
>> +++ b/drivers/usb/dwc2/platform.c
>> @@ -156,6 +156,8 @@ static int dwc2_driver_probe(struct platform_device *dev)
>> params.dma_desc_enable = prop;
>> }
>>
>> + spin_lock_init(&hsotg->lock);
>> +
>> if (IS_ENABLED(CONFIG_USB_DWC2_HOST)) {
>> retval = dwc2_hcd_init(hsotg, irq, ¶ms);
>> if (retval)
>> @@ -175,7 +177,6 @@ static int dwc2_driver_probe(struct platform_device *dev)
>> if (retval)
>> return retval;
>> }
>> - spin_lock_init(&hsotg->lock);
>>
>> platform_set_drvdata(dev, hsotg);
>> return retval;
>> --
>
> Hmm. What tree is this against? platform.c in both Linus' tree and in
> Greg's usb-next tree does not have a call to spin_lock_init().
>
> --
> Paul
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC ipsec-next] xfrm: make sha256 icv truncation length RFC-compliant
Le 23/05/2014 08:28, Horia Geantă a écrit : On 5/22/2014 7:03 PM, Nicolas Dichtel wrote: Le 22/05/2014 17:10, Horia Geanta a écrit : From: Lei Xu Currently the sha256 icv truncation length is set to 96bit while the length is defined as 128bit in RFC4868. This may result in somer errors when working with other IPsec devices with the standard truncation length. Thus, change the sha256 truncation length from 96bit to 128bit. The patch was already proposed, but it was kept as-is for userspace compatibility. See: https://lkml.org/lkml/2012/3/7/431 Thanks, somehow I missed that. So this just means bad luck for user space tools (for e.g. ipsec-tools - setkey, racoon - and any other PF_KEY-based tool) that AFAICT cannot override the default truncated icv size, right? You can change the default value with the netlink attribute XFRMA_ALG_AUTH_TRUNC (option 'auth-trunc' in iproute2). Regards, Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 00/14] Add Qualcomm SD Card Controller support
On 23/05/14 08:50, Ulf Hansson wrote: On 23 May 2014 09:13, Srinivas Kandagatla wrote: Hi Ulf, I like to get this patches for v3.16, any chance of considering these patches to v3.16 ? I promise to have them properly reviewed early next week, sorry for taking so long. Let's see where this leads us. Thankyou. It seems like you had some CRC issues during read/write? Did you manage to resolve that issue? Bjorn is using different SOC and board than the IFC6410 Am testing on, so its completely different setup. on IFC6410 we did lot of stress testing and no issues seen. so suspecting the issues are very specific to that board or the eMMC Bjorn is using. We are suspecting that the CRC issues are due to the fact that there is no code to manage regulators. My test setup uses dummy regulator, and the eMMC and external SD cards seems to be Ok with default voltages. Am not sure if thats the same with Bjorn's board. Thanks, srini Kind regards Ulf Hansson -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2 00/14] perf tools: Speedup DWARF unwind
ping ;-) thanks, jirka On Thu, May 15, 2014 at 07:23:21PM +0200, Jiri Olsa wrote: > hi, > trying to speedup DWARF unwind report code by factoring > related code: > - caching sample's registers access > - keep dso data file descriptor open for the > life of the dso object > - replace dso cache code by mapping dso data file > directly for the life of the dso object > > The speedup is mainly for libunwind unwind. The libdw will benefit > mainly from cached registers access, because it handles dso data > accesses by itself.. and anyway it's still faster ;-). > > v2 changes: > - adding limit for open dso objects with sort of LRU > mechanism to pick up and close dso objects if we > are over the limit > - file mmaping changes are omitted, because I couldn't prove > the improvement exactly, will resubmit later > - added dso close logic in case of no memory > - added tests > > On 10GB perf data file with dwarf unwind data I've got > around 30% speed up. > > Also reachable in here: > git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git > perf/core_unwind_speedup > > thanks, > jirka > > Cc: Arnaldo Carvalho de Melo > Cc: Corey Ashford > Cc: David Ahern > Cc: Frederic Weisbecker > Cc: Ingo Molnar > Cc: Jean Pihet > Cc: Namhyung Kim > Cc: Paul Mackerras > Cc: Peter Zijlstra > Signed-off-by: Jiri Olsa > --- > Jiri Olsa (14): > perf tools: Cache register accesses for unwind processing > perf tools: Separate dso data related variables > perf tools: Add data_fd into dso object > perf tools: Add global list of opened dso objects > perf tools: Add global count of opened dso objects > perf tools: Cache dso data file descriptor > perf tools: Add file size check and factor dso__data_read_offset > perf tools: Allow to close dso fd in case of open failure > perf tools: Add dso__data_* interface descriptons > perf tests: Spawn child for each test > perf tests: Allow reuse of test_file function > perf tests: Add test interface for dso data fd limit > perf tests: Add test for caching dso file descriptors > perf tests: Add test for closing dso objects on EMFILE error > > tools/perf/tests/builtin-test.c| 42 ++- > tools/perf/tests/dso-data.c| 256 > +++-- > tools/perf/tests/tests.h | 2 + > tools/perf/util/dso.c | 274 > +++- > tools/perf/util/dso.h | 56 +++- > tools/perf/util/event.h| 5 ++ > tools/perf/util/perf_regs.c| 10 +++- > tools/perf/util/perf_regs.h| 4 +- > tools/perf/util/unwind-libunwind.c | 4 +- > 9 files changed, 617 insertions(+), 36 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 00/16] OMAP: GPMC: Restructure OMAP GPMC driver (NAND) : DT binding change proposal
Ezequiel & Javier,
On 05/22/2014 05:46 PM, Ezequiel Garcia wrote:
> On 22 May 01:51 PM, Javier Martinez Canillas wrote:
>> On Thu, May 22, 2014 at 10:12 AM, Roger Quadros wrote:
On 21 May 02:20 PM, Roger Quadros wrote:
>
> For DT boot:
> - The GPMC controller node should have a chip select (CS) node for each
> used
> chip select. The CS node must have a child device node for each device
> attached to that chip select. Properties for that child are GPMC
> agnostic.
>
> i.e.
> gpmc {
> cs0 {
> nand0 {
> }
> };
>
> cs1 {
> nor0 {
> }
> }
> ...
> };
>
While I agree that the GPMC driver is a bit messy, I'm not sure it's
possible
to go through such a complete devicetree binding re-design (breaking
backwards
compatibility) now that the binding is already in production.
>>>
>>> Why not? especially if the existing bindings are poorly dones. Is anyone
>>> using these
>>> bindings burning the DT into ROM and can't change it when they update the
>>> kernel?
>>>
>>
>> While I do agree that your DT bindings are much better than the
>> current ones, there is a policy that DT bindings are an external API
>> and once are released with a kernel are set in stone and can't be
>> changed.
>>
>
> Exactly. The DT binding is considered an ABI. Thus, invariant across kernel
> versions. Users can't be coherced into a DTB update after a kernel update.
>
> That said, I don't really care if you break compatilibity in this case.
> Rather, I'm suggesting that you make sure this change is going to be accepted
> upstream, before doing any more work. The DT maintainers are reluctant to do
> so.
Appreciate your concern.
Would be really nice if you can review patches 1-12. They have nothing to do
with DT changes.
Thanks.
cheers,
-roger
>
> On the other side, I guess you will also break bisectability while breaking
> backward compatibility. Doesn't sound very nice.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 01/22] serial: 8250_dw: Add optional reset control support
On Friday 23 May 2014 15:51:04 Chen-Yu Tsai wrote: > p->regshift = val; > > + data->rst = devm_reset_control_get_optional(p->dev, NULL); > + > /* clock got configured through clk api, all done */ > if (p->uartclk) > return 0; > @@ -362,6 +366,9 @@ static int dw8250_probe(struct platform_device *pdev) > return -ENODEV; > } > > + if (!IS_ERR_OR_NULL(data->rst)) > + reset_control_deassert(data->rst); > + You should basically never use IS_ERR_OR_NULL(). devm_reset_control_get_optional() doesn't return NULL, so IS_ERR() should be safe. Alternatively, change the code above to set data->rst to NULL if there is no reset line or error out if you get a different error (e.g. EPROBE_DEFER). Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/20/2014 05:19 PM, Serge Hallyn wrote: > Quoting Andy Lutomirski (l...@amacapital.net): >> On May 15, 2014 1:26 PM, "Serge E. Hallyn" wrote: >>> >>> Quoting Richard Weinberger (rich...@nod.at): Am 15.05.2014 21:50, schrieb Serge Hallyn: > Quoting Richard Weinberger (richard.weinber...@gmail.com): >> On Thu, May 15, 2014 at 4:08 PM, Greg Kroah-Hartman >> wrote: >>> Then don't use a container to build such a thing, or fix the build >>> scripts to not do that :) >> >> I second this. To me it looks like some folks try to (ab)use Linux >> containers for purposes where KVM >> would much better fit in. Please don't put more complexity into >> containers. They are already horrible >> complex and error prone. > > I, naturally, disagree :) The only use case which is inherently not > valid for containers is running a > kernel. Practically speaking there are other things which likely will > never be possible, but if someone > offers a way to do something in containers, "you can't do that in > containers" is not an apropos response. > > "That abstraction is wrong" is certainly valid, as when vpids were > originally proposed and rejected, > resulting in the development of pid namespaces. "We have to work out (x) > first" can be valid (and I can > think of examples here), assuming it's not just trying to hide behind a > catch-22/chicken-egg problem. > > Finally, saying "containers are complex and error prone" is conflating > several large suites of userspace > code and many kernel features which support them. Being more precise > would, if the argument is valid, lend > it a lot more weight. We (my company) use Linux containers since 2011 in production. First LXC, now libvirt-lxc. To understand the internals better I also wrote my own userspace to create/start containers. There are so many things which can hurt you badly. With user namespaces we expose a really big attack surface to regular users. I.e. Suddenly a user is allowed to mount filesystems. >>> >>> That is currently not the case. They can mount some virtual filesystems >>> and do bind mounts, but cannot mount >>> most real filesystems. This keeps us protected (for now) from potentially >>> unsafe superblock readers in the >>> kernel. >>> Ask Andy, he found already lots of nasty things... >> >> I don't think I have anything brilliant to add to this discussion right now, >> except possibly: >> >> ISTM that Linux distributions are, in general, vulnerable to all kinds of >> shenanigans that would happen if an >> untrusted user can cause a block device to appear. That user doesn't need >> permission to mount it > > Interesting point. This would further suggest that we absolutely must ensure > that a loop device which shows up in > the container does not also show up in the host. Can I suggest the usage of the devices cgroup to achieve that? Marian > >> or even necessarily to change its contents on the fly. >> >> E.g. what happens if you boot a machine that contains a malicious disk image >> that has the same partition UUID as >> /? Nothing good, I imagine. >> >> So if we're going to go down this road, we really need some way to tell the >> host that certain devices are not >> trusted. >> >> --Andy > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to > majord...@vger.kernel.org More majordomo info at > http://vger.kernel.org/majordomo-info.html Please read the FAQ at > http://www.tux.org/lkml/ > - -- Marian Marinov Founder & CEO of 1H Ltd. Jabber/GTalk: hack...@jabber.org ICQ: 7556201 Mobile: +359 886 660 270 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlN/BL8ACgkQ4mt9JeIbjJRuTwCgjpP8cNle5deHpUSJJoDkcfin byEAn3Fy4wwiZ3avNwA/ljZWVWeGFU8W =iQLO -END PGP SIGNATURE- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Tux3 for review
Hi Dongsu, On Thursday, May 22, 2014 2:52:27 AM PDT, Dongsu Park wrote: First of all, thank you for trying to merge it to mainline. Maybe I cannot say the code is clean enough, but basically the filesystem seems to work at least. Thank you for confirming that. We test Tux3 extensively so we know it works pretty well (short of enospc handling) but independent confirmation carries more weight than anything we could say. Our standard disclaimer: Tux3 is for developers right now, not for users. ...The files named "*_hack" were kept as close as possible to the original core code to clarify exactly where core needs to change in order to remove our workarounds. If you think we should pretty up that code then we will happily do it. Or maybe we can hammer out acceptable core patches right now, and include those ... Looking up kallsyms is not only hacky, but also making the filesystem unable to be mounted at all, when CONFIG_KALLSYMS_ALL is not defined. I'll send out patches to fix that separately to tux3 mailing list. Thank you for improving the hack. We are working on getting rid of that flusher hack completely. There is a patch under development to introduce a new super_operationss.writeback() operation that allows a filesystem to flush its own inodes instead of letting core do it. This will allow Tux3 to enforce its strong ordering semantics efficiently without needing to reimplement part of fs-writeback.c. Regards, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: usbip: use kcalloc instead of kzalloc for array allocations
The advantage of kcalloc is, that will prevent integer overflows which could
result from the multiplication of number of elements and size and it is also
a bit nicer to read.
Signed-off-by: Djordje Zekovic
---
drivers/staging/usbip/stub_tx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/usbip/stub_tx.c b/drivers/staging/usbip/stub_tx.c
index 1622563..4994090 100644
--- a/drivers/staging/usbip/stub_tx.c
+++ b/drivers/staging/usbip/stub_tx.c
@@ -179,7 +179,7 @@ static int stub_send_ret_submit(struct stub_device *sdev)
else
iovnum = 2;
- iov = kzalloc(iovnum * sizeof(struct kvec), GFP_KERNEL);
+ iov = kcalloc(iovnum * sizeof(struct kvec), GFP_KERNEL);
if (!iov) {
usbip_event_add(&sdev->ud, SDEV_EVENT_ERROR_MALLOC);
--
1.8.5.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 2/3] ARM: dts: oma3-gta04: Add display support
On 08/05/14 23:16, Marek Belisko wrote: > This patch add support for lcd display on gta04 board. Display control > is connected to spi (used spi bitbang driver). > > Signed-off-by: Marek Belisko > --- > arch/arm/boot/dts/omap3-gta04.dts | 87 > +++ > 1 file changed, 87 insertions(+) I can take this via my tree. Tony, can I have your ack on this? Tomi signature.asc Description: OpenPGP digital signature
[PATCH 14/22] clk: sunxi: Add A23 APB0 support to sun6i-a31-apb0-clk
The A23 has an almost identical PRCM clock tree. The difference in
the APB0 clock is the smallest divisor is 1, instead of 2.
This patch extends the sun6i-a31-apb0-clk driver to take divider
tables associated to compatibles, and adds a compatible for the A23
variant.
Signed-off-by: Chen-Yu Tsai
---
Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
drivers/clk/sunxi/clk-sun6i-apb0.c| 28 ++-
2 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt
b/Documentation/devicetree/bindings/clock/sunxi.txt
index fa927ba..ae94bbf 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -29,6 +29,7 @@ Required properties:
"allwinner,sun8i-a23-ahb1-gates-clk" - for the AHB1 gates on A23
"allwinner,sun4i-a10-apb0-clk" - for the APB0 clock
"allwinner,sun6i-a31-apb0-clk" - for the APB0 clock on A31
+ "allwinner,sun8i-a23-apb0-clk" - for the APB0 clock on A23
"allwinner,sun4i-a10-apb0-gates-clk" - for the APB0 gates on A10
"allwinner,sun5i-a13-apb0-gates-clk" - for the APB0 gates on A13
"allwinner,sun5i-a10s-apb0-gates-clk" - for the APB0 gates on A10s
diff --git a/drivers/clk/sunxi/clk-sun6i-apb0.c
b/drivers/clk/sunxi/clk-sun6i-apb0.c
index 11f17c3..2197ac7 100644
--- a/drivers/clk/sunxi/clk-sun6i-apb0.c
+++ b/drivers/clk/sunxi/clk-sun6i-apb0.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
/*
@@ -28,6 +29,21 @@ static const struct clk_div_table sun6i_a31_apb0_divs[] = {
{ /* sentinel */ },
};
+/* The A23 APB0 clock has a standard power of 2 divisor */
+static const struct clk_div_table sun8i_a23_apb0_divs[] = {
+ { .val = 0, .div = 1, },
+ { .val = 1, .div = 2, },
+ { .val = 2, .div = 4, },
+ { .val = 3, .div = 8, },
+ { /* sentinel */ },
+};
+
+const struct of_device_id sun6i_a31_apb0_clk_dt_ids[] = {
+ { .compatible = "allwinner,sun6i-a31-apb0-clk", .data =
&sun6i_a31_apb0_divs },
+ { .compatible = "allwinner,sun8i-a23-apb0-clk", .data =
&sun8i_a23_apb0_divs },
+ { /* sentinel */ }
+};
+
static int sun6i_a31_apb0_clk_probe(struct platform_device *pdev)
{
struct device_node *np = pdev->dev.of_node;
@@ -36,12 +52,17 @@ static int sun6i_a31_apb0_clk_probe(struct platform_device
*pdev)
struct resource *r;
void __iomem *reg;
struct clk *clk;
+ const struct of_device_id *device;
r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
reg = devm_ioremap_resource(&pdev->dev, r);
if (IS_ERR(reg))
return PTR_ERR(reg);
+ device = of_match_device(sun6i_a31_apb0_clk_dt_ids, &pdev->dev);
+ if (!device)
+ return -EINVAL;
+
clk_parent = of_clk_get_parent_name(np, 0);
if (!clk_parent)
return -EINVAL;
@@ -49,7 +70,7 @@ static int sun6i_a31_apb0_clk_probe(struct platform_device
*pdev)
of_property_read_string(np, "clock-output-names", &clk_name);
clk = clk_register_divider_table(&pdev->dev, clk_name, clk_parent,
-0, reg, 0, 2, 0, sun6i_a31_apb0_divs,
+0, reg, 0, 2, 0, device->data,
NULL);
if (IS_ERR(clk))
return PTR_ERR(clk);
@@ -57,11 +78,6 @@ static int sun6i_a31_apb0_clk_probe(struct platform_device
*pdev)
return of_clk_add_provider(np, of_clk_src_simple_get, clk);
}
-const struct of_device_id sun6i_a31_apb0_clk_dt_ids[] = {
- { .compatible = "allwinner,sun6i-a31-apb0-clk" },
- { /* sentinel */ }
-};
-
static struct platform_driver sun6i_a31_apb0_clk_driver = {
.driver = {
.name = "sun6i-a31-apb0-clk",
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/22] clk: sunxi: Support factor clocks with N multiplier factor starting from 1
The PLLs on newer Allwinner SoC's, such as the A31 and A23, have a
N multiplier factor that starts from 1, not 0.
This patch adds an option to the clock driver's config data structures
to define the difference.
Signed-off-by: Chen-Yu Tsai
---
drivers/clk/sunxi/clk-factors.c | 5 -
drivers/clk/sunxi/clk-factors.h | 1 +
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/sunxi/clk-factors.c b/drivers/clk/sunxi/clk-factors.c
index 3806d97..399cf4d 100644
--- a/drivers/clk/sunxi/clk-factors.c
+++ b/drivers/clk/sunxi/clk-factors.c
@@ -62,7 +62,10 @@ static unsigned long clk_factors_recalc_rate(struct clk_hw
*hw,
p = FACTOR_GET(config->pshift, config->pwidth, reg);
/* Calculate the rate */
- rate = (parent_rate * n * (k + 1) >> p) / (m + 1);
+ if (config->n_from_one)
+ rate = (parent_rate * (n + 1) * (k + 1) >> p) / (m + 1);
+ else
+ rate = (parent_rate * n * (k + 1) >> p) / (m + 1);
return rate;
}
diff --git a/drivers/clk/sunxi/clk-factors.h b/drivers/clk/sunxi/clk-factors.h
index 02e1a43..0484a48 100644
--- a/drivers/clk/sunxi/clk-factors.h
+++ b/drivers/clk/sunxi/clk-factors.h
@@ -15,6 +15,7 @@ struct clk_factors_config {
u8 mwidth;
u8 pshift;
u8 pwidth;
+ u8 n_from_one;
};
struct clk_factors {
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 15/22] pinctrl: sunxi: Add A23 PIO controller support
The A23 uses the same pin controller as previous SoC's from Allwinner.
Add support for the pins controlled by the main PIO controller.
Signed-off-by: Chen-Yu Tsai
---
.../bindings/pinctrl/allwinner,sunxi-pinctrl.txt | 2 +
drivers/pinctrl/sunxi/Kconfig | 4 +
drivers/pinctrl/sunxi/Makefile | 1 +
drivers/pinctrl/sunxi/pinctrl-sun8i-a23.c | 562 +
4 files changed, 569 insertions(+)
create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun8i-a23.c
diff --git
a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
index d8d0656..93ce12e 100644
--- a/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/allwinner,sunxi-pinctrl.txt
@@ -13,6 +13,8 @@ Required properties:
"allwinner,sun6i-a31-pinctrl"
"allwinner,sun6i-a31-r-pinctrl"
"allwinner,sun7i-a20-pinctrl"
+ "allwinner,sun8i-a23-pinctrl"
+ "allwinner,sun8i-a23-r-pinctrl"
- reg: Should contain the register physical address and length for the
pin controller.
diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
index da1e830..17a4281 100644
--- a/drivers/pinctrl/sunxi/Kconfig
+++ b/drivers/pinctrl/sunxi/Kconfig
@@ -32,4 +32,8 @@ config PINCTRL_SUN7I_A20
def_bool PINCTRL_SUNXI || MACH_SUN7I
select PINCTRL_SUNXI_COMMON
+config PINCTRL_SUN8I_A23
+ def_bool PINCTRL_SUNXI || MACH_SUN8I
+ select PINCTRL_SUNXI_COMMON
+
endif
diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
index 0f4461c..850cd50 100644
--- a/drivers/pinctrl/sunxi/Makefile
+++ b/drivers/pinctrl/sunxi/Makefile
@@ -8,3 +8,4 @@ obj-$(CONFIG_PINCTRL_SUN5I_A13) += pinctrl-sun5i-a13.o
obj-$(CONFIG_PINCTRL_SUN6I_A31)+= pinctrl-sun6i-a31.o
obj-$(CONFIG_PINCTRL_SUN6I_A31_R) += pinctrl-sun6i-a31-r.o
obj-$(CONFIG_PINCTRL_SUN7I_A20)+= pinctrl-sun7i-a20.o
+obj-$(CONFIG_PINCTRL_SUN8I_A23)+= pinctrl-sun8i-a23.o
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun8i-a23.c
b/drivers/pinctrl/sunxi/pinctrl-sun8i-a23.c
new file mode 100644
index 000..5e045a6
--- /dev/null
+++ b/drivers/pinctrl/sunxi/pinctrl-sun8i-a23.c
@@ -0,0 +1,562 @@
+/*
+ * Allwinner A23 SoCs pinctrl driver.
+ *
+ * Copyright (C) 2014 Chen-Yu Tsai
+ *
+ * Chen-Yu Tsai
+ *
+ * Copyright (C) 2014 Maxime Ripard
+ *
+ * Maxime Ripard
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include "pinctrl-sunxi.h"
+
+static const struct sunxi_desc_pin sun8i_a23_pins[] = {
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 0),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "spi1"), /* CS */
+ SUNXI_FUNCTION(0x3, "jtag")), /* MS0 */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 1),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "spi1"), /* CLK */
+ SUNXI_FUNCTION(0x3, "jtag")), /* CKO */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 2),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "spi1"), /* MOSI */
+ SUNXI_FUNCTION(0x3, "jtag")), /* DOO */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 3),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "spi1"), /* MISO */
+ SUNXI_FUNCTION(0x3, "jtag")), /* DIO */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 4),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "uart4")),/* TX */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 5),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "uart4")),/* RX */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 6),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "uart4")),/* RTS */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 7),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "uart4")),/* CTS */
+ /* Hole */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 0),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCT
[PATCH 13/22] clk: sunxi: Add A23 clocks support
The clock control unit on the A23 is similar to the one found on the A31.
The AHB1, APB1, APB2 gates on the A23 are almost identical to the ones
on the A31, but some outputs are missing.
The main CPU PLL (PLL1) however is like that on older Allwinner SoCs, such
as the A10 or A20, but the N factor starts from 1 instead of 0.
This patch adds support for PLL1 and all the basic clock gates.
Signed-off-by: Chen-Yu Tsai
---
Documentation/devicetree/bindings/clock/sunxi.txt | 4 ++
drivers/clk/sunxi/clk-sunxi.c | 83 +++
2 files changed, 87 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt
b/Documentation/devicetree/bindings/clock/sunxi.txt
index ae18ec1..fa927ba 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -9,6 +9,7 @@ Required properties:
"allwinner,sun4i-a10-osc-clk" - for a gatable oscillator
"allwinner,sun4i-a10-pll1-clk" - for the main PLL clock and PLL4
"allwinner,sun6i-a31-pll1-clk" - for the main PLL clock on A31
+ "allwinner,sun8i-a23-pll1-clk" - for the main PLL clock on A23
"allwinner,sun4i-a10-pll5-clk" - for the PLL5 clock
"allwinner,sun4i-a10-pll6-clk" - for the PLL6 clock
"allwinner,sun6i-a31-pll6-clk" - for the PLL6 clock on A31
@@ -25,6 +26,7 @@ Required properties:
AHB1 on A31
"allwinner,sun6i-a31-ahb1-mux-clk" - for the AHB1 multiplexer on A31
"allwinner,sun6i-a31-ahb1-gates-clk" - for the AHB1 gates on A31
+ "allwinner,sun8i-a23-ahb1-gates-clk" - for the AHB1 gates on A23
"allwinner,sun4i-a10-apb0-clk" - for the APB0 clock
"allwinner,sun6i-a31-apb0-clk" - for the APB0 clock on A31
"allwinner,sun4i-a10-apb0-gates-clk" - for the APB0 gates on A10
@@ -39,8 +41,10 @@ Required properties:
"allwinner,sun5i-a10s-apb1-gates-clk" - for the APB1 gates on A10s
"allwinner,sun6i-a31-apb1-gates-clk" - for the APB1 gates on A31
"allwinner,sun7i-a20-apb1-gates-clk" - for the APB1 gates on A20
+ "allwinner,sun8i-a23-apb1-gates-clk" - for the APB1 gates on A23
"allwinner,sun6i-a31-apb2-div-clk" - for the APB2 gates on A31
"allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31
+ "allwinner,sun8i-a23-apb2-gates-clk" - for the APB2 gates on A23
"allwinner,sun4i-a10-mod0-clk" - for the module 0 family of clocks
"allwinner,sun7i-a20-out-clk" - for the external output clocks
"allwinner,sun7i-a20-gmac-clk" - for the GMAC clock module on A20/A31
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 89eadbc..1d16c0c 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -164,6 +164,54 @@ static void sun6i_a31_get_pll1_factors(u32 *freq, u32
parent_rate,
}
/**
+ * sun8i_a23_get_pll1_factors() - calculates n, k, m, p factors for PLL1
+ * PLL1 rate is calculated as follows
+ * rate = (parent_rate * (n + 1) * (k + 1) >> p) / (m + 1);
+ * parent_rate is always 24Mhz
+ */
+
+static void sun8i_a23_get_pll1_factors(u32 *freq, u32 parent_rate,
+ u8 *n, u8 *k, u8 *m, u8 *p)
+{
+ u8 div;
+
+ /* Normalize value to a 6M multiple */
+ div = *freq / 600;
+ *freq = 600 * div;
+
+ /* we were called to round the frequency, we can now return */
+ if (n == NULL)
+ return;
+
+ /* m is always zero for pll1 */
+ *m = 0;
+
+ /* k is 1 only on these cases */
+ if (*freq >= 76800 || *freq == 4200 || *freq == 5400)
+ *k = 1;
+ else
+ *k = 0;
+
+ /* p will be 2 for divs under 20 and odd divs under 32 */
+ if (div < 20 || (div < 32 && (div & 1)))
+ *p = 2;
+
+ /* p will be 1 for even divs under 32, divs under 40 and odd pairs
+* of divs between 40-62 */
+ else if (div < 40 || (div < 64 && (div & 2)))
+ *p = 1;
+
+ /* any other entries have p = 0 */
+ else
+ *p = 0;
+
+ /* calculate a suitable n based on k and p */
+ div <<= *p;
+ div /= (*k + 1);
+ *n = div / 4 - 1;
+}
+
+/**
* sun4i_get_pll5_factors() - calculates n, k factors for PLL5
* PLL5 rate is calculated as follows
* rate = parent_rate * n * (k + 1)
@@ -422,6 +470,18 @@ static struct clk_factors_config sun6i_a31_pll1_config = {
.mwidth = 2,
};
+static struct clk_factors_config sun8i_a23_pll1_config = {
+ .nshift = 8,
+ .nwidth = 5,
+ .kshift = 4,
+ .kwidth = 2,
+ .mshift = 0,
+ .mwidth = 2,
+ .pshift = 16,
+ .pwidth = 2,
+ .n_from_one = 1,
+};
+
static struct clk_factors_config sun4i_pll5_config = {
.nshift = 8,
.nwidth = 5,
@@ -472,6 +532,12 @@ static const struct factors_data sun6i_a31_pll1_data
__i
[PATCH 00/21] ARM: sunxi: Introduce Allwinner A23 (sun8i) support
Hi everyone, This patch series introduces basic kernel support for Allwinner's A23 SoC, which we will call the sun8i platform. This includes basic clocks, timers, interrupts, pinctrl, and UARTs. The series can also be found here: https://github.com/wens/linux/tree/sunxi-a23 The A23 is a mix of Allwinner's previous A20 (sun7i) and A31 (sun6i) SoC's, but also a step forward. Most of the IP blocks are the same as in the A31, with some features stripped out. However it has a Mali GPU, Instead of a PowerVR. The patches below are a result of comparing the current working sun6i platform with the A23 user manual, and various kernel and u-boot sources for A23 and A31 from Allwinner. The series is based on sunxi-next (6c90cef), with the following patches applied: pinctrl: sunxi: Fix multiple registration issue pinctrl: sunxi: Fix recursive dependency pinctrl: sunxi: fix pin numbers passed to register offset helpers The first 12 patches are fixes, which will also be used by sun8i. Hopefully these won't have any issues so we can get them in and fix up some stuff queued up for 3.16. Patch 1 adds optional support for reset controls to 8250_dw, which is used on sun6i. The reset controls must be de-asserted for the UART to function. Patch 2 registers the sunxi clock gates with clkdev, so the "protect important clock" code will work with them. Patch 3 adds "pll6" to the list of protected clocks on sun6i. Some unknown module, likely MBUS, uses pll6. Until we have a driver for it, we should make sure pll6 is not disabled. Patch 4 moves "ahb_sdram" clock protection into the protected clocks list on sun4i, sun5i, and sun7i. Patch 5 fixes gate indexing for sun6i PRCM APB0 gates introduced during this cycle. The index mapping was incorrect when "clock-indicies" was used and there were gaps between the used gates. Patches 6~7 correct clock factor and clock rate calculations for PLL6 on sun6i, which has a multiplier factor starting from 1, instead of 0 in previous SoC's. Patch 8~9 changes the sun6i PLL6 driver to a multiple divider output clock, like the ones found on previous SoCs. This yields the properly halved clock rate for normal users of PLL6, but also supports the full rate for future clock modules to use. Patch 10 adds support for the pre-divider on the PLL6 input to the AHB1 clock. Patches 11~12 are the DT changes matching patches 6~10. The remaining patches add new support for A23 related modules. Patch 13 adds support for the basic clock modules found on the A23. Patch 14 adds support for the PRCM clocks found on the A23, notably the APB0 clock, which has a different divider table. Patches 15 and 16 add the pin sets for the A23 PIO and A23 R_PIO blocks, respectively. Patch 17 adds A23 PRCM support to the sun6i-prcm mfd driver. The A23 PRCM uses a slightly different subdevice list. Patch 18 and 20 add machine and SMP support for the A23. Patch 19 adds a Kconfig option to use R_UART as early console. Patch 21 adds the DTSI for A23 (sun8i). Patch 22 adds the DT for the Ippo-q8h (v5) tablet. This tablet is one of the earliest available A23 devices. So far we have seen 2 revisions of the mainboard inside the tablet. The version I have is a v5, which has an unsupported SDIO WiFi chip. The other known version uses a RTL8188 USB WiFi chip. Greg, could you pick up the first patch? Emilio, Mike, patches 2~5 fixes clock code queued up in Emilio's tree, hopefully we can apply these fixes together. Patches 6~10 fix the sun6i PLL6 implementation already in the kernel. I hope we can get them in as well. Maxime, if Emilio takes the fixes, could you take the corresponding DT (patches 11~12) changes? I've ordered the new A31 Hummingbird board, but it hasn't shipped yet, so I don't have any actual A31 hardware to test these fixes on. I am relying on the A23 CCU and PRCM units being essentially the same as the A31 ones. So if anyone has A31 hardware and also some spare time, please test them on your hardware. As for the A23 patches, it seems a bit late to include them in 3.16, assuming no changes are required. There might be a conflict with Maxime's restart code patches. Any suggestions? Cheers ChenYu Chen-Yu Tsai (22): serial: 8250_dw: Add optional reset control support clk: sunxi: register clock gates with clkdev clk: sunxi: add "pll6" to sun6i protected clock list clk: sunxi: move "ahb_sdram" to protected clock list clk: sunxi: Fix gate indexing for sun6i-a31-apb0-gates clk: sunxi: Support factor clocks with N multiplier factor starting from 1 clk: sunxi: Fix PLL6 calculation on sun6i clk: sunxi: Specify number of child clocks for divs clocks clk: sunxi: Implement A31 PLL6 as a divs clock for 2x output clk: sunxi: Add support for PLL6 pre-divider on AHB1 clock ARM: sun6i: DT: Add PLL6 multiple outputs ARM: sun6i: DT: Add PLL6 pre-divider clock for AHB1 mux input clk: sunxi: Add A23 clocks support clk: sunxi: Add A23 APB0 support to sun6i-a31-apb0-clk
[PATCH 03/22] clk: sunxi: add "pll6" to sun6i protected clock list
PLL6 is used by some important but undocumented module, most likely
memory related, such as mbus or the actual memory controller. As we
do not have a driver for that, add pll6 to the list of protected
clocks, so that it won't be disabled and leave us with a non-responsive
system.
Signed-off-by: Chen-Yu Tsai
---
drivers/clk/sunxi/clk-sunxi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index e0e24d5..3e33bc1 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -1229,6 +1229,7 @@ CLK_OF_DECLARE(sun7i_a20_clk_init, "allwinner,sun7i-a20",
sun5i_init_clocks);
static const char *sun6i_critical_clocks[] __initdata = {
"cpu",
+ "pll6", /* something we don't know about uses pll6 */
"ahb1_sdram",
};
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 17/22] mfd: sun6i-prcm: Add support for Allwinner A23 PRCM
The Allwinner A23 SoC has a PRCM unit like the previous A31 SoC.
The differences are the AR100 clock can no longer be modified,
and the APB0 clock has different divisors.
This patch adds a compatible with a modified subdevice list for
the A23.
Signed-off-by: Chen-Yu Tsai
---
.../devicetree/bindings/mfd/sun6i-prcm.txt | 2 +-
drivers/mfd/sun6i-prcm.c | 30 ++
2 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt
b/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt
index 1f5a31f..03c5a55 100644
--- a/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt
+++ b/Documentation/devicetree/bindings/mfd/sun6i-prcm.txt
@@ -4,7 +4,7 @@ PRCM is an MFD device exposing several Power Management related
devices
(like clks and reset controllers).
Required properties:
- - compatible: "allwinner,sun6i-a31-prcm"
+ - compatible: "allwinner,sun6i-a31-prcm" or "allwinner,sun8i-a23-prcm"
- reg: The PRCM registers range
The prcm node may contain several subdevices definitions:
diff --git a/drivers/mfd/sun6i-prcm.c b/drivers/mfd/sun6i-prcm.c
index 718fc4d..c96bb6c 100644
--- a/drivers/mfd/sun6i-prcm.c
+++ b/drivers/mfd/sun6i-prcm.c
@@ -76,16 +76,46 @@ static const struct mfd_cell sun6i_a31_prcm_subdevs[] = {
},
};
+static const struct mfd_cell sun8i_a23_prcm_subdevs[] = {
+ {
+ .name = "sun6i-a31-apb0-clk",
+ .of_compatible = "allwinner,sun8i-a23-apb0-clk",
+ .num_resources = ARRAY_SIZE(sun6i_a31_apb0_clk_res),
+ .resources = sun6i_a31_apb0_clk_res,
+ },
+ {
+ .name = "sun6i-a31-apb0-gates-clk",
+ .of_compatible = "allwinner,sun6i-a31-apb0-gates-clk",
+ .num_resources = ARRAY_SIZE(sun6i_a31_apb0_gates_clk_res),
+ .resources = sun6i_a31_apb0_gates_clk_res,
+ },
+ {
+ .name = "sun6i-a31-apb0-clock-reset",
+ .of_compatible = "allwinner,sun6i-a31-clock-reset",
+ .num_resources = ARRAY_SIZE(sun6i_a31_apb0_rstc_res),
+ .resources = sun6i_a31_apb0_rstc_res,
+ },
+};
+
static const struct prcm_data sun6i_a31_prcm_data = {
.nsubdevs = ARRAY_SIZE(sun6i_a31_prcm_subdevs),
.subdevs = sun6i_a31_prcm_subdevs,
};
+static const struct prcm_data sun8i_a23_prcm_data = {
+ .nsubdevs = ARRAY_SIZE(sun8i_a23_prcm_subdevs),
+ .subdevs = sun8i_a23_prcm_subdevs,
+};
+
static const struct of_device_id sun6i_prcm_dt_ids[] = {
{
.compatible = "allwinner,sun6i-a31-prcm",
.data = &sun6i_a31_prcm_data,
},
+ {
+ .compatible = "allwinner,sun8i-a23-prcm",
+ .data = &sun8i_a23_prcm_data,
+ },
{ /* sentinel */ },
};
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/22] clk: sunxi: register clock gates with clkdev
The new important clock protect code requires the clocks be registered with clkdev. This was missing for sunxi_gates type clocks. Signed-off-by: Chen-Yu Tsai --- drivers/clk/sunxi/clk-sunxi.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c index 96ba00c..e0e24d5 100644 --- a/drivers/clk/sunxi/clk-sunxi.c +++ b/drivers/clk/sunxi/clk-sunxi.c @@ -899,6 +899,7 @@ static void __init sunxi_gates_clk_setup(struct device_node *node, reg + 4 * (i/32), i % 32, 0, &clk_lock); WARN_ON(IS_ERR(clk_data->clks[i])); + clk_register_clkdev(clks[i], clk_name, NULL); j++; } -- 2.0.0.rc2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/22] clk: sunxi: Fix PLL6 calculation on sun6i
The N factor for PLL6 counts from 1 to 32, as specified in the A23
manual, and shown in Allwinner's original code.
This patch fixes the N factor in the clock driver, as well as the
comment describing it.
Signed-off-by: Chen-Yu Tsai
---
drivers/clk/sunxi/clk-sunxi.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index b2c6d12..6500a1b 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -198,7 +198,7 @@ static void sun4i_get_pll5_factors(u32 *freq, u32
parent_rate,
/**
* sun6i_a31_get_pll6_factors() - calculates n, k factors for A31 PLL6
* PLL6 rate is calculated as follows
- * rate = parent_rate * n * (k + 1) / 2
+ * rate = parent_rate * (n + 1) * (k + 1) / 2
* parent_rate is always 24Mhz
*/
@@ -225,7 +225,7 @@ static void sun6i_a31_get_pll6_factors(u32 *freq, u32
parent_rate,
if (*k > 3)
*k = 3;
- *n = DIV_ROUND_UP(div, (*k+1));
+ *n = DIV_ROUND_UP(div, (*k+1)) - 1;
}
/**
@@ -434,6 +434,7 @@ static struct clk_factors_config sun6i_a31_pll6_config = {
.nwidth = 5,
.kshift = 4,
.kwidth = 2,
+ .n_from_one = 1,
};
static struct clk_factors_config sun4i_apb1_config = {
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 16/22] pinctrl: sunxi: Add A23 R_PIO controller support
The A23 has a R_PIO pin controller, similar to the one found on the A31 SoC.
Add support for the pins controlled by the R_PIO controller.
Signed-off-by: Chen-Yu Tsai
---
drivers/pinctrl/sunxi/Kconfig | 4 +
drivers/pinctrl/sunxi/Makefile | 1 +
drivers/pinctrl/sunxi/pinctrl-sun8i-a23-r.c | 129
3 files changed, 134 insertions(+)
create mode 100644 drivers/pinctrl/sunxi/pinctrl-sun8i-a23-r.c
diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
index 17a4281..3058d32 100644
--- a/drivers/pinctrl/sunxi/Kconfig
+++ b/drivers/pinctrl/sunxi/Kconfig
@@ -36,4 +36,8 @@ config PINCTRL_SUN8I_A23
def_bool PINCTRL_SUNXI || MACH_SUN8I
select PINCTRL_SUNXI_COMMON
+config PINCTRL_SUN8I_A23_R
+ def_bool PINCTRL_SUNXI || MACH_SUN8I
+ select PINCTRL_SUNXI_COMMON
+
endif
diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
index 850cd50..e797efb 100644
--- a/drivers/pinctrl/sunxi/Makefile
+++ b/drivers/pinctrl/sunxi/Makefile
@@ -9,3 +9,4 @@ obj-$(CONFIG_PINCTRL_SUN6I_A31) += pinctrl-sun6i-a31.o
obj-$(CONFIG_PINCTRL_SUN6I_A31_R) += pinctrl-sun6i-a31-r.o
obj-$(CONFIG_PINCTRL_SUN7I_A20)+= pinctrl-sun7i-a20.o
obj-$(CONFIG_PINCTRL_SUN8I_A23)+= pinctrl-sun8i-a23.o
+obj-$(CONFIG_PINCTRL_SUN8I_A23_R) += pinctrl-sun8i-a23-r.o
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun8i-a23-r.c
b/drivers/pinctrl/sunxi/pinctrl-sun8i-a23-r.c
new file mode 100644
index 000..ae17888
--- /dev/null
+++ b/drivers/pinctrl/sunxi/pinctrl-sun8i-a23-r.c
@@ -0,0 +1,129 @@
+/*
+ * Allwinner A23 SoCs special pins pinctrl driver.
+ *
+ * Copyright (C) 2014 Chen-Yu Tsai
+ * Chen-Yu Tsai
+ *
+ * Copyright (C) 2014 Boris Brezillon
+ * Boris Brezillon
+ *
+ * Copyright (C) 2014 Maxime Ripard
+ * Maxime Ripard
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "pinctrl-sunxi.h"
+
+static const struct sunxi_desc_pin sun8i_a23_r_pins[] = {
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 0),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "s_rsb"), /* SCK */
+ SUNXI_FUNCTION(0x3, "s_twi")),/* SCK */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 1),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "s_rsb"), /* SDA */
+ SUNXI_FUNCTION(0x3, "s_twi")),/* SDA */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 2),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "s_uart")), /* TX */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 3),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "s_uart")), /* RX */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 4),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x3, "s_jtag")), /* MS */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 5),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x3, "s_jtag")), /* CK */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 6),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x3, "s_jtag")), /* DO */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 7),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x3, "s_jtag")), /* DI */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 8),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "s_twi")),/* SCK */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 9),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "s_twi")),/* SDA */
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 10),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out"),
+ SUNXI_FUNCTION(0x2, "s_pwm")),
+ SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 11),
+ SUNXI_FUNCTION(0x0, "gpio_in"),
+ SUNXI_FUNCTION(0x1, "gpio_out")),
+};
+
+static const struct sunxi_pinctrl_desc sun8i_a23_r_pinctrl_data = {
+ .pins = sun8i_a23_r_pins,
+ .npins = ARRAY_SIZE(sun8i_a23_r_pins),
+ .pin_base = PL_BASE,
+};
+
+st
Re: [PATCH v5 00/49] DaVinci: vpif: upgrade with v4l helpers and v4l compliance fixes
Hi Prabhakar, Thanks for this patch series, it looks good to me and I'll make a pull request for this. I did find a few issues, but they are all pre-existing problems, so they can be fixed in follow-up patches. I'll comment on those in the relevant patches. Since display and capture are so similar I will only comment on the display patches, but it's valid for both. Regards, Hans On 05/16/2014 03:33 PM, Lad, Prabhakar wrote: > From: "Lad, Prabhakar" > > Hi, > > This patch series upgrades the vpif capture & display > driver with the all the helpers provided by v4l, this makes > the driver much simpler and cleaner. This also includes few > checkpatch issues. > > Changes for v2: > a> Added a copyright. > b> Dropped buf_init() callback from vb2_ops. > c> Fixed enabling & disabling of interrupts in case of HD formats. > > Changes for v3: > a> Fixed review comments pointed by Hans. > > Changes for v4: Rebased the patches on media tree. > > Changes for v5: Split up the patches > > Following is the output of v4l-compliance for capture: > -- > > ./v4l2-compliance -d /dev/video0 -i 0 -s -v --expbuf-device=2 > > Driver Info: > Driver name : vpif_capture > Card type : DA850/OMAP-L138 Video Capture > Bus info : platform:vpif_capture > Driver version: 3.15.0 > Capabilities : 0x8401 > Video Capture > Streaming > Device Capabilities > Device Caps : 0x0401 > Video Capture > Streaming > > Compliance test for device /dev/video0 (not using libv4l2): > > Required ioctls: > test VIDIOC_QUERYCAP: OK > > Allow for multiple opens: > test second video open: OK > test VIDIOC_QUERYCAP: OK > test VIDIOC_G/S_PRIORITY: OK > > Debug ioctls: > test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) > test VIDIOC_LOG_STATUS: OK > > Input ioctls: > test VIDIOC_G/S_TUNER: OK (Not Supported) > test VIDIOC_G/S_FREQUENCY: OK (Not Supported) > test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) > test VIDIOC_ENUMAUDIO: OK (Not Supported) > test VIDIOC_G/S/ENUMINPUT: OK > test VIDIOC_G/S_AUDIO: OK (Not Supported) > Inputs: 1 Audio Inputs: 0 Tuners: 0 > > Output ioctls: > test VIDIOC_G/S_MODULATOR: OK (Not Supported) > test VIDIOC_G/S_FREQUENCY: OK (Not Supported) > test VIDIOC_ENUMAUDOUT: OK (Not Supported) > test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) > test VIDIOC_G/S_AUDOUT: OK (Not Supported) > Outputs: 0 Audio Outputs: 0 Modulators: 0 > > Input/Output configuration ioctls: > test VIDIOC_ENUM/G/S/QUERY_STD: OK > test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) > test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) > test VIDIOC_G/S_EDID: OK (Not Supported) > > Test input 0: > > Control ioctls: > test VIDIOC_QUERYCTRL/MENU: OK (Not Supported) > test VIDIOC_G/S_CTRL: OK (Not Supported) > test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported) > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported) > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) > Standard Controls: 0 Private Controls: 0 > > Format ioctls: > info: found 1 formats for buftype 1 > test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK > fail: v4l2-test-formats.cpp(1003): cap->readbuffers > test VIDIOC_G/S_PARM: FAIL > test VIDIOC_G_FBUF: OK (Not Supported) > test VIDIOC_G_FMT: OK > test VIDIOC_TRY_FMT: OK > test VIDIOC_S_FMT: OK > test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) > > Codec ioctls: > test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) > test VIDIOC_G_ENC_INDEX: OK (Not Supported) > test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) > > Buffer ioctls: > info: test buftype Video Capture > test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK > test VIDIOC_EXPBUF: OK > test read/write: OK (Not Supported) > Video Capture: > Buffer: 0 Sequence: 0 Field: Interlaced Timestamp: 145.509130s > Buffer: 1 Sequence: 0 Field: Interlaced Timestamp: 145.549125s > Buffer: 2 Sequence: 0 Field: Interlaced Timestamp: 145.589148s > Buffer: 3 Sequence: 0 Field: Interlaced Timestamp: 145.629106s > Buffer: 0 Sequence: 0 Field: Interlaced Timestamp: 145.669110s > Buffer: 1 Sequence: 0 Field: Interlaced Timestamp: 145.709102s > Buffer: 2 Sequence: 0 Field: Interlaced Timestamp: 145.749099s > Buffer: 3 Sequence: 0 Field
Re: [PATCH] staging: usbip: use kcalloc instead of kzalloc for array allocations
On Fri, May 23, 2014 at 12:17 PM, Djordje Zekovic wrote: > The advantage of kcalloc is, that will prevent integer overflows which could > result from the multiplication of number of elements and size and it is also > a bit nicer to read. > > Signed-off-by: Djordje Zekovic > --- > drivers/staging/usbip/stub_tx.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/staging/usbip/stub_tx.c b/drivers/staging/usbip/stub_tx.c > index 1622563..4994090 100644 > --- a/drivers/staging/usbip/stub_tx.c > +++ b/drivers/staging/usbip/stub_tx.c > @@ -179,7 +179,7 @@ static int stub_send_ret_submit(struct stub_device *sdev) > else > iovnum = 2; > > - iov = kzalloc(iovnum * sizeof(struct kvec), GFP_KERNEL); > + iov = kcalloc(iovnum * sizeof(struct kvec), GFP_KERNEL); Does this even build? static inline void *kcalloc(size_t n, size_t size, gfp_t flags) -- Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] sound branch of STMPE cleanups
> as seen in linux-next something is screwed up on the immutable > branch for STMPE cleanups, can you pull this instead, it is > the known tested good version with no compilation regressions. > > I have no hurry to get this into the GPIO tree anymore, I will push > additionall changes to the next merge window, simply. Nope, this branch is broken too. I don't think this is a merge error, I think it's programmer error (even the greats make mistakes =:-) ). Take a look at the patch: http://paste.ubuntu.com/7504677/ You remove all instances of irq_base except the one in stmpe_irq_init(). I'll fix this up for you and re-push/tag the branch. The references will be the same, so you just need to re-fetch and re-merge. I'll give you the node once it's ready. In the mean time, it might be worth you looking at your build system, as it seems to be overlooking drivers/mfd/stmpe.c. > The following changes since commit 89ca3b881987f5a4be4c5dbaa7f0df12bbdde2fd: > > Linux 3.15-rc4 (2014-05-04 18:14:42 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git > stmpe-for-lee > > for you to fetch changes up to decc1ca8b2e5ae947fd9679f8adbd056d3b47d30: > > mfd: stmpe: mask off unused blocks properly (2014-05-23 00:19:12 +0200) > > > Linus Walleij (4): > mfd: stmpe: root out static GPIO and IRQ assignments > mfd: stmpe: add optional regulators > mfd: stmpe: probe properly from the device tree > mfd: stmpe: mask off unused blocks properly > > drivers/gpio/gpio-stmpe.c | 18 +- > drivers/mfd/Kconfig | 1 + > drivers/mfd/stmpe-i2c.c | 30 +- > drivers/mfd/stmpe.c | 30 -- > drivers/mfd/stmpe.h | 2 +- > include/linux/mfd/stmpe.h | 19 +-- > 6 files changed, 69 insertions(+), 31 deletions(-) -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/22] clk: sunxi: Specify number of child clocks for divs clocks
Currently sunxi_divs_clk_setup assumes the number of child clocks
to be the same as the number of clock-output-names, and a maximum
of SUNXI_DIVS_MAX_QTY child clocks.
On sun6i, PLL6 only has 1 child clock, but the parent would be used
as well, thereby also having it's own clock-output-names entry. This
results in an extra bogus clock being registered.
This patch adds an entry for the number of child clocks alongside
the data structures for them.
Signed-off-by: Chen-Yu Tsai
---
drivers/clk/sunxi/clk-sunxi.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 6500a1b..6857c6e 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -933,6 +933,7 @@ static void __init sunxi_gates_clk_setup(struct device_node
*node,
struct divs_data {
const struct factors_data *factors; /* data for the factor clock */
+ int ndivs; /* number of children */
struct {
u8 fixed; /* is it a fixed divisor? if not... */
struct clk_div_table *table; /* is it a table based divisor? */
@@ -952,6 +953,7 @@ static struct clk_div_table pll6_sata_tbl[] = {
static const struct divs_data pll5_divs_data __initconst = {
.factors = &sun4i_pll5_data,
+ .ndivs = 2,
.div = {
{ .shift = 0, .pow = 0, }, /* M, DDR */
{ .shift = 16, .pow = 1, }, /* P, other */
@@ -960,6 +962,7 @@ static const struct divs_data pll5_divs_data __initconst = {
static const struct divs_data pll6_divs_data __initconst = {
.factors = &sun4i_pll6_data,
+ .ndivs = 2,
.div = {
{ .shift = 0, .table = pll6_sata_tbl, .gate = 14 }, /* M, SATA
*/
{ .fixed = 2 }, /* P, other */
@@ -990,7 +993,7 @@ static void __init sunxi_divs_clk_setup(struct device_node
*node,
struct clk_fixed_factor *fix_factor;
struct clk_divider *divider;
void *reg;
- int i = 0;
+ int ndivs = SUNXI_DIVS_MAX_QTY, i = 0;
int flags, clkflags;
/* Set up factor clock that we will be dividing */
@@ -1013,7 +1016,11 @@ static void __init sunxi_divs_clk_setup(struct
device_node *node,
* our RAM clock! */
clkflags = !strcmp("pll5", parent) ? 0 : CLK_SET_RATE_PARENT;
- for (i = 0; i < SUNXI_DIVS_MAX_QTY; i++) {
+ /* if number of children known, use it */
+ if (data->ndivs)
+ ndivs = data->ndivs;
+
+ for (i = 0; i < ndivs; i++) {
if (of_property_read_string_index(node, "clock-output-names",
i, &clk_name) != 0)
break;
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/22] clk: sunxi: Add support for PLL6 pre-divider on AHB1 clock
On the A31 and A23, the PLL6 input to the AHB1 clock has a 2 bit wide
pre-divider. This was verified from the A23 user manual and A31/A23 SDK
sources.
Signed-off-by: Chen-Yu Tsai
---
Documentation/devicetree/bindings/clock/sunxi.txt | 2 ++
drivers/clk/sunxi/clk-sunxi.c | 7 +++
2 files changed, 9 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt
b/Documentation/devicetree/bindings/clock/sunxi.txt
index b9ec668..ae18ec1 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -21,6 +21,8 @@ Required properties:
"allwinner,sun5i-a10s-ahb-gates-clk" - for the AHB gates on A10s
"allwinner,sun7i-a20-ahb-gates-clk" - for the AHB gates on A20
"allwinner,sun6i-a31-ar100-clk" - for the AR100 on A31
+ "allwinner,sun6i-a31-ahb1-pll6-clk" - for the PLL6 pre-divider to
+ AHB1 on A31
"allwinner,sun6i-a31-ahb1-mux-clk" - for the AHB1 multiplexer on A31
"allwinner,sun6i-a31-ahb1-gates-clk" - for the AHB1 gates on A31
"allwinner,sun4i-a10-apb0-clk" - for the APB0 clock
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 339cabc..89eadbc 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -686,6 +686,12 @@ static const struct div_data sun4i_apb0_data __initconst =
{
.width = 2,
};
+static const struct div_data sun6i_a31_ahb1_pll6_data __initconst = {
+ .shift = 6,
+ .pow= 0,
+ .width = 2,
+};
+
static const struct div_data sun6i_a31_apb2_div_data __initconst = {
.shift = 0,
.pow= 0,
@@ -1128,6 +1134,7 @@ static const struct of_device_id clk_div_match[]
__initconst = {
{.compatible = "allwinner,sun4i-a10-axi-clk", .data = &sun4i_axi_data,},
{.compatible = "allwinner,sun4i-a10-ahb-clk", .data = &sun4i_ahb_data,},
{.compatible = "allwinner,sun4i-a10-apb0-clk", .data =
&sun4i_apb0_data,},
+ {.compatible = "allwinner,sun6i-a31-ahb1-pll6-clk", .data =
&sun6i_a31_ahb1_pll6_data,},
{.compatible = "allwinner,sun6i-a31-apb2-div-clk", .data =
&sun6i_a31_apb2_div_data,},
{}
};
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/22] clk: sunxi: Implement A31 PLL6 as a divs clock for 2x output
Some clock modules on the A31 use PLL6x2 as one of their inputs.
This patch changes the PLL6 implementation for A31 to a divs clock,
i.e. clock with multiple outputs that have different dividers.
This behavior is consistent with previous SoC's by Allwinner.
Signed-off-by: Chen-Yu Tsai
---
drivers/clk/sunxi/clk-sunxi.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 6857c6e..339cabc 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -496,6 +496,7 @@ static const struct factors_data sun6i_a31_pll6_data
__initconst = {
.enable = 31,
.table = &sun6i_a31_pll6_config,
.getter = sun6i_a31_get_pll6_factors,
+ .name = "pll6",
};
static const struct factors_data sun4i_apb1_data __initconst = {
@@ -969,6 +970,14 @@ static const struct divs_data pll6_divs_data __initconst =
{
}
};
+static const struct divs_data sun6i_a31_pll6_divs_data __initconst = {
+ .factors = &sun6i_a31_pll6_data,
+ .ndivs = 1,
+ .div = {
+ { .fixed = 2 }, /* P, other */
+ }
+};
+
/**
* sunxi_divs_clk_setup() - Setup function for leaf divisors on clocks
*
@@ -1108,7 +1117,6 @@ static const struct of_device_id clk_factors_match[]
__initconst = {
{.compatible = "allwinner,sun4i-a10-pll1-clk", .data =
&sun4i_pll1_data,},
{.compatible = "allwinner,sun6i-a31-pll1-clk", .data =
&sun6i_a31_pll1_data,},
{.compatible = "allwinner,sun7i-a20-pll4-clk", .data =
&sun7i_a20_pll4_data,},
- {.compatible = "allwinner,sun6i-a31-pll6-clk", .data =
&sun6i_a31_pll6_data,},
{.compatible = "allwinner,sun4i-a10-apb1-clk", .data =
&sun4i_apb1_data,},
{.compatible = "allwinner,sun4i-a10-mod0-clk", .data =
&sun4i_mod0_data,},
{.compatible = "allwinner,sun7i-a20-out-clk", .data =
&sun7i_a20_out_data,},
@@ -1128,6 +1136,7 @@ static const struct of_device_id clk_div_match[]
__initconst = {
static const struct of_device_id clk_divs_match[] __initconst = {
{.compatible = "allwinner,sun4i-a10-pll5-clk", .data =
&pll5_divs_data,},
{.compatible = "allwinner,sun4i-a10-pll6-clk", .data =
&pll6_divs_data,},
+ {.compatible = "allwinner,sun6i-a31-pll6-clk", .data =
&sun6i_a31_pll6_divs_data,},
{}
};
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 18/22] ARM: sunxi: Introduce Allwinner A23 support
The Allwinner A23 is a dual-core Cortex-A7-based SoC. It re-uses most of
the IPs found in previous SoCs, notably the A31.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/mach-sunxi/Kconfig | 8
arch/arm/mach-sunxi/sunxi.c | 12
2 files changed, 20 insertions(+)
diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunxi/Kconfig
index 0fbd4f1..6434e3b 100644
--- a/arch/arm/mach-sunxi/Kconfig
+++ b/arch/arm/mach-sunxi/Kconfig
@@ -35,4 +35,12 @@ config MACH_SUN7I
select HAVE_ARM_ARCH_TIMER
select SUN5I_HSTIMER
+config MACH_SUN8I
+ bool "Allwinner A23 (sun8i) SoCs support"
+ default ARCH_SUNXI
+ select ARCH_HAS_RESET_CONTROLLER
+ select ARM_GIC
+ select MFD_SUN6I_PRCM
+ select RESET_CONTROLLER
+
endif
diff --git a/arch/arm/mach-sunxi/sunxi.c b/arch/arm/mach-sunxi/sunxi.c
index df906e3..a43b295 100644
--- a/arch/arm/mach-sunxi/sunxi.c
+++ b/arch/arm/mach-sunxi/sunxi.c
@@ -159,3 +159,15 @@ DT_MACHINE_START(SUN7I_DT, "Allwinner sun7i (A20) Family")
.dt_compat = sun7i_board_dt_compat,
.restart= sun4i_restart,
MACHINE_END
+
+static const char * const sun8i_board_dt_compat[] = {
+ "allwinner,sun8i-a23",
+ NULL,
+};
+
+DT_MACHINE_START(SUN8I_DT, "Allwinner sun8i (A23) Family")
+ .init_machine = sunxi_dt_init,
+ .init_time = sun6i_timer_init,
+ .dt_compat = sun8i_board_dt_compat,
+ .restart= sun6i_restart,
+MACHINE_END
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH trivial] of: dma: Grammar s/requests/request/, s/used required/required/
Signed-off-by: Geert Uytterhoeven --- Documentation/devicetree/bindings/dma/dma.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/devicetree/bindings/dma/dma.txt b/Documentation/devicetree/bindings/dma/dma.txt index 8f504e6bae14..82104271e754 100644 --- a/Documentation/devicetree/bindings/dma/dma.txt +++ b/Documentation/devicetree/bindings/dma/dma.txt @@ -14,7 +14,7 @@ Required property: Optional properties: - dma-channels:Number of DMA channels supported by the controller. -- dma-requests:Number of DMA requests signals supported by the +- dma-requests:Number of DMA request signals supported by the controller. Example: @@ -44,7 +44,7 @@ Required property: #dma-cells property in the node referenced by phandle containing DMA controller specific information. This typically contains a DMA request line number or a - channel number, but can contain any data that is used + channel number, but can contain any data that is required for configuring a channel. - dma-names: Contains one identifier string for each DMA specifier in the dmas property. The specific strings that can be used -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 22/22] ARM: sun8i: dt: Add Ippo-q8h v5 support
The Ippo-q8h is a tablet circiut board commonly found in cheap Android
tablets with A23 SoCs. There are at least 2 versions of the board, with
different peripherals, such as WiFi chips.
This patch add supports for v5 of such boards, which has a ESP8089 WiFi
chip (not supported) connected to mmc1.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/Makefile | 2 ++
arch/arm/boot/dts/sun8i-a23-ippo-q8h-v5.dts | 51 +
2 files changed, 53 insertions(+)
create mode 100644 arch/arm/boot/dts/sun8i-a23-ippo-q8h-v5.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 6967393..f809a53 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -354,6 +354,8 @@ dtb-$(CONFIG_MACH_SUN7I) += \
sun7i-a20-cubietruck.dtb \
sun7i-a20-i12-tvbox.dtb \
sun7i-a20-olinuxino-micro.dtb
+dtb-$(CONFIG_MACH_SUN8I) += \
+ sun8i-a23-ippo-q8h-v5.dtb
dtb-$(CONFIG_ARCH_TEGRA) += tegra20-harmony.dtb \
tegra20-iris-512.dtb \
tegra20-medcom-wide.dtb \
diff --git a/arch/arm/boot/dts/sun8i-a23-ippo-q8h-v5.dts
b/arch/arm/boot/dts/sun8i-a23-ippo-q8h-v5.dts
new file mode 100644
index 000..7d0bd97
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-a23-ippo-q8h-v5.dts
@@ -0,0 +1,51 @@
+/*
+ * Copyright 2014 Chen-Yu Tsai
+ *
+ * Chen-Yu Tsai
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+/include/ "sun8i-a23.dtsi"
+
+/ {
+ model = "Ippo Q8H Dual Core Tablet (v5)";
+ compatible = "ippo,q8h-v5", "allwinner,sun8i-a23";
+
+ chosen {
+ bootargs = "earlyprintk console=ttyS0,115200";
+ };
+
+ soc@01c0 {
+ uart0: serial@01c28000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_pins_a>;
+ status = "okay";
+ };
+
+ i2c0: i2c@01c2ac00 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c0_pins_a>;
+ status = "okay";
+ };
+
+ i2c1: i2c@01c2b000 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1_pins_a>;
+ status = "okay";
+ };
+
+ r_uart: serial@01f02800 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&r_uart_pins_a>;
+ status = "okay";
+ };
+ };
+};
+
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 12/22] ARM: sun6i: DT: Add PLL6 pre-divider clock for AHB1 mux input
On the A31, the PLL6 input to the AHB1 clock has a 2 bit wide
pre-divider. This was verified from the A23 user manual and
A31/A23 SDK sources.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun6i-a31.dtsi | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index d9643fa..d8808fe 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -125,11 +125,19 @@
clock-output-names = "axi";
};
+ ahb1_pll6: ahb1_pll6_clk@01c20054 {
+ #clock-cells = <0>;
+ compatible = "allwinner,sun6i-a31-ahb1-pll6-clk";
+ reg = <0x01c20054 0x4>;
+ clocks = <&pll6 0>;
+ clock-output-names = "ahb1_pll6";
+ };
+
ahb1_mux: ahb1_mux@01c20054 {
#clock-cells = <0>;
compatible = "allwinner,sun6i-a31-ahb1-mux-clk";
reg = <0x01c20054 0x4>;
- clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6 0>;
+ clocks = <&osc32k>, <&osc24M>, <&axi>, <&ahb1_pll6>;
clock-output-names = "ahb1_mux";
};
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] mm, compaction: properly signal and act upon lock and need_sched() contention
On 05/23/2014 04:48 AM, Shawn Guo wrote:
> On 23 May 2014 07:49, Kevin Hilman wrote:
>> On Fri, May 16, 2014 at 2:47 AM, Vlastimil Babka wrote:
>>> Compaction uses compact_checklock_irqsave() function to periodically check
>>> for
>>> lock contention and need_resched() to either abort async compaction, or to
>>> free the lock, schedule and retake the lock. When aborting, cc->contended is
>>> set to signal the contended state to the caller. Two problems have been
>>> identified in this mechanism.
>>
>> This patch (or later version) has hit next-20140522 (in the form
>> commit 645ceea9331bfd851bc21eea456dda27862a10f4) and according to my
>> bisect, appears to be the culprit of several boot failures on ARM
>> platforms.
>
> On i.MX6 where CMA is enabled, the commit causes the drivers calling
> dma_alloc_coherent() fail to probe. Tracing it a little bit, it seems
> dma_alloc_from_contiguous() always return page as NULL after this
> commit.
>
> Shawn
>
Really sorry, guys :/
-8<-
From: Vlastimil Babka
Date: Fri, 23 May 2014 10:18:56 +0200
Subject:
mm-compaction-properly-signal-and-act-upon-lock-and-need_sched-contention-fix2
Step 1: Change function name and comment between v1 and v2 so that the return
value signals the opposite thing.
Step 2: Change the call sites to reflect the opposite return value.
Step 3: ???
Step 4: Make a complete fool of yourself.
Signed-off-by: Vlastimil Babka
---
mm/compaction.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/compaction.c b/mm/compaction.c
index a525cd4..5175019 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -237,13 +237,13 @@ static inline bool compact_should_abort(struct
compact_control *cc)
if (need_resched()) {
if (cc->mode == MIGRATE_ASYNC) {
cc->contended = true;
- return false;
+ return true;
}
cond_resched();
}
- return true;
+ return false;
}
/* Returns true if the page is within a block suitable for migration to */
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/6] wdt: sunxi: Move restart code to the watchdog driver
On Thu, May 22, 2014 at 02:12:07PM -0700, Guenter Roeck wrote: > On Thu, May 22, 2014 at 10:34:44PM +0200, Maxime Ripard wrote: > > On Mon, May 19, 2014 at 05:04:22PM +0200, Maxime Ripard wrote: > > > On Thu, May 15, 2014 at 11:11:23AM +0200, Maxime Ripard wrote: > > > > On Wed, May 07, 2014 at 02:33:18PM -0700, Guenter Roeck wrote: > > > > > On Tue, May 06, 2014 at 09:44:19PM -0500, Maxime Ripard wrote: > > > > > > Most of the watchdog code is duplicated between the machine restart > > > > > > code and > > > > > > the watchdog driver. Add the restart hook to the watchdog driver, > > > > > > to be able to > > > > > > remove it from the machine code eventually. > > > > > > > > > > > > Signed-off-by: Maxime Ripard > > > > > > Acked-by: Arnd Bergmann > > > > > > > > > > Reviewed-by: Guenter Roeck > > > > > > > > Wim, do you have any comment on this one? > > > > > > Ping? > > > > > > It would be really great to see this in 3.16, and we get quite close > > > to the end of ARM's merge window. > > > > Ping? > > > > Guenter, since you seem to be the only responsive, may I suggest that > > you start merging patches and do a pull request to either Wim or Linus > > directly during the merge window? > > > I had prepared a pull request for Wim last weekend or so, but then there > were more patches piling in and I got distracted, so I didn't have time > to actually send it. I'll try again this weekend ... the kids should be > busy learning for their finals, and I'll have Friday and Monday off > from work, so I should be able to find the time. > > As for sending patches to Linus directly, well, Wim is the watchdog > maintainer. > I manage to upset enough people, and would not want to add Wim to the list. > > The patches _are_ in my watchdog-next branch and get some coverage from > both my auto-builders and from Fenguang's build robots, so while they are > not in linux-next, they are not completely in the dark either. Ok, so I can merge the other patches then. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH v5 04/49] media: davinci: vpif_display: release buffers in case start_streaming() call back fails
On 05/16/2014 03:33 PM, Lad, Prabhakar wrote:
> From: "Lad, Prabhakar"
>
> this patch adds support to release the buffer by calling
> vb2_buffer_done(), with state marked as VB2_BUF_STATE_QUEUED
> if start_streaming() call back fails.
>
> Signed-off-by: Lad, Prabhakar
> ---
> drivers/media/platform/davinci/vpif_display.c | 42
> +++--
> 1 file changed, 26 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/media/platform/davinci/vpif_display.c
> b/drivers/media/platform/davinci/vpif_display.c
> index 8bb9f02..1a17a45 100644
> --- a/drivers/media/platform/davinci/vpif_display.c
> +++ b/drivers/media/platform/davinci/vpif_display.c
> @@ -196,26 +196,16 @@ static int vpif_start_streaming(struct vb2_queue *vq,
> unsigned int count)
> struct channel_obj *ch = vb2_get_drv_priv(vq);
> struct common_obj *common = &ch->common[VPIF_VIDEO_INDEX];
> struct vpif_params *vpif = &ch->vpifparams;
> - unsigned long addr = 0;
> - unsigned long flags;
> + struct vpif_disp_buffer *buf, *tmp;
> + unsigned long addr, flags;
> int ret;
>
> spin_lock_irqsave(&common->irqlock, flags);
>
> - /* Get the next frame from the buffer queue */
> - common->next_frm = common->cur_frm =
> - list_entry(common->dma_queue.next,
> -struct vpif_disp_buffer, list);
> -
> - list_del(&common->cur_frm->list);
> - spin_unlock_irqrestore(&common->irqlock, flags);
> - /* Mark state of the current frame to active */
> - common->cur_frm->vb.state = VB2_BUF_STATE_ACTIVE;
> -
> /* Initialize field_id and started member */
> ch->field_id = 0;
> common->started = 1;
> - addr = vb2_dma_contig_plane_dma_addr(&common->cur_frm->vb, 0);
> +
> /* Calculate the offset for Y and C data in the buffer */
> vpif_calculate_offsets(ch);
>
> @@ -225,7 +215,8 @@ static int vpif_start_streaming(struct vb2_queue *vq,
> unsigned int count)
> || (!ch->vpifparams.std_info.frm_fmt
> && (common->fmt.fmt.pix.field == V4L2_FIELD_NONE))) {
> vpif_err("conflict in field format and std format\n");
> - return -EINVAL;
> + ret = -EINVAL;
> + goto err;
> }
>
> /* clock settings */
> @@ -234,17 +225,28 @@ static int vpif_start_streaming(struct vb2_queue *vq,
> unsigned int count)
> ycmux_mode, ch->vpifparams.std_info.hd_sd);
> if (ret < 0) {
> vpif_err("can't set clock\n");
> - return ret;
> + goto err;
> }
> }
>
> /* set the parameters and addresses */
> ret = vpif_set_video_params(vpif, ch->channel_id + 2);
> if (ret < 0)
> - return ret;
> + goto err;
>
> common->started = ret;
> vpif_config_addr(ch, ret);
> + /* Get the next frame from the buffer queue */
> + common->next_frm = common->cur_frm =
> + list_entry(common->dma_queue.next,
> +struct vpif_disp_buffer, list);
> +
> + list_del(&common->cur_frm->list);
> + spin_unlock_irqrestore(&common->irqlock, flags);
> + /* Mark state of the current frame to active */
> + common->cur_frm->vb.state = VB2_BUF_STATE_ACTIVE;
There is no need to set this, all buffers queued to the driver are always in
state
ACTIVE. The vb2 core sets that for you. In general drivers never need to change
the
state manually.
It happens twice in this driver and in both cases the assignment can be removed.
Regards,
Hans
> +
> + addr = vb2_dma_contig_plane_dma_addr(&common->cur_frm->vb, 0);
> common->set_addr((addr + common->ytop_off),
> (addr + common->ybtm_off),
> (addr + common->ctop_off),
> @@ -271,6 +273,14 @@ static int vpif_start_streaming(struct vb2_queue *vq,
> unsigned int count)
> }
>
> return 0;
> +
> +err:
> + list_for_each_entry_safe(buf, tmp, &common->dma_queue, list) {
> + list_del(&buf->list);
> + vb2_buffer_done(&buf->vb, VB2_BUF_STATE_QUEUED);
> + }
> +
> + return ret;
> }
>
> /* abort streaming and wait for last buffer */
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/22] clk: sunxi: move "ahb_sdram" to protected clock list
With sunxi_gates clocks registered with clkdev, we can use the
protected clocks list to enable the "ahb_sdram" clock, instead
of looking for it and adding CLK_IGNORE_UNUSED inline in the
clock setup code.
Signed-off-by: Chen-Yu Tsai
---
drivers/clk/sunxi/clk-sunxi.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 3e33bc1..b2c6d12 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -870,7 +870,6 @@ static void __init sunxi_gates_clk_setup(struct device_node
*node,
int qty;
int i = 0;
int j = 0;
- int ignore;
reg = of_iomap(node, 0);
@@ -891,15 +890,12 @@ static void __init sunxi_gates_clk_setup(struct
device_node *node,
of_property_read_string_index(node, "clock-output-names",
j, &clk_name);
- /* No driver claims this clock, but it should remain gated */
- ignore = !strcmp("ahb_sdram", clk_name) ? CLK_IGNORE_UNUSED : 0;
-
clk_data->clks[i] = clk_register_gate(NULL, clk_name,
- clk_parent, ignore,
+ clk_parent, 0,
reg + 4 * (i/32), i % 32,
0, &clk_lock);
WARN_ON(IS_ERR(clk_data->clks[i]));
- clk_register_clkdev(clks[i], clk_name, NULL);
+ clk_register_clkdev(clk_data->clks[i], clk_name, NULL);
j++;
}
@@ -1204,6 +1200,7 @@ static void __init sunxi_init_clocks(const char
*clocks[], int nclocks)
static const char *sun4i_a10_critical_clocks[] __initdata = {
"pll5_ddr",
+ "ahb_sdram",
};
static void __init sun4i_a10_init_clocks(void)
@@ -1216,6 +1213,7 @@ CLK_OF_DECLARE(sun4i_a10_clk_init, "allwinner,sun4i-a10",
sun4i_a10_init_clocks)
static const char *sun5i_critical_clocks[] __initdata = {
"mbus",
"pll5_ddr",
+ "ahb_sdram",
};
static void __init sun5i_init_clocks(void)
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 21/22] ARM: sunxi: Add Allwinner A23 dtsi
The Allwinner A23 is a tablet oriented SoC with 2 Cortex-A7 cores
and a Mali-400MP2 GPU.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun8i-a23.dtsi | 524 +++
1 file changed, 524 insertions(+)
create mode 100644 arch/arm/boot/dts/sun8i-a23.dtsi
diff --git a/arch/arm/boot/dts/sun8i-a23.dtsi b/arch/arm/boot/dts/sun8i-a23.dtsi
new file mode 100644
index 000..1cff087
--- /dev/null
+++ b/arch/arm/boot/dts/sun8i-a23.dtsi
@@ -0,0 +1,524 @@
+/*
+ * Copyright 2014 Chen-Yu Tsai
+ *
+ * Chen-Yu Tsai
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+ interrupt-parent = <&gic>;
+
+ aliases {
+ serial0 = &uart0;
+ serial1 = &uart1;
+ serial2 = &uart2;
+ serial3 = &uart3;
+ serial4 = &uart4;
+ serial5 = &r_uart;
+ };
+
+
+ cpus {
+ enable-method = "allwinner,sun8i-a23";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ compatible = "arm,cortex-a7";
+ device_type = "cpu";
+ reg = <0>;
+ clocks = <&cpu>;
+ };
+
+ cpu@1 {
+ compatible = "arm,cortex-a7";
+ device_type = "cpu";
+ reg = <1>;
+ clocks = <&cpu>;
+ };
+ };
+
+ memory {
+ reg = <0x4000 0x8000>;
+ };
+
+ pmu {
+ compatible = "arm,cortex-a7-pmu", "arm,cortex-a15-pmu";
+ interrupts = <0 120 4>,
+<0 121 4>,
+<0 122 4>,
+<0 123 4>;
+ };
+
+ clocks {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ osc24M: osc24M_clk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <2400>;
+ clock-output-names = "osc24M";
+ };
+
+ osc32k: osc32k_clk {
+ #clock-cells = <0>;
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+ clock-output-names = "osc32k";
+ };
+
+ pll1: clk@01c2 {
+ #clock-cells = <0>;
+ compatible = "allwinner,sun8i-a23-pll1-clk";
+ reg = <0x01c2 0x4>;
+ clocks = <&osc24M>;
+ clock-output-names = "pll1";
+ };
+
+ pll6: clk@01c20028 {
+ #clock-cells = <1>;
+ compatible = "allwinner,sun6i-a31-pll6-clk";
+ reg = <0x01c20028 0x4>;
+ clocks = <&osc24M>;
+ clock-output-names = "pll6_other", "pll6";
+ };
+
+ cpu: cpu_clk@01c20050 {
+ #clock-cells = <0>;
+ compatible = "allwinner,sun4i-a10-cpu-clk";
+ reg = <0x01c20050 0x4>;
+
+ /*
+* PLL1 is listed twice here.
+* While it looks suspicious, it's actually documented
+* that way both in the datasheet and in the code from
+* Allwinner.
+*/
+ clocks = <&osc32k>, <&osc24M>, <&pll1>, <&pll1>;
+ clock-output-names = "cpu";
+ };
+
+ axi: axi_clk@01c20050 {
+ #clock-cells = <0>;
+ /*
+* AXI clock on A23 is actually wider,
+* but extra bit is useless for divider
+*/
+ compatible = "allwinner,sun4i-a10-axi-clk";
+ reg = <0x01c20050 0x4>;
+ clocks = <&cpu>;
+ clock-output-names = "axi";
+ };
+
+ ahb1_pll6: ahb1_pll6_clk@01c20054 {
+ #clock-cells = <0>;
+ compatible = "allwinner,sun6i-a31-ahb1-pll6-clk";
+ reg = <0x01c20054 0x4>;
+ clocks = <&pll6 0>;
+ clock-output-names = "ahb1_pll6";
+ };
+
+ ahb1_mux: ahb1_mux_clk@01c20054 {
+ #clock-cells = <0>;
+ compatible = "al
[PATCH 05/22] clk: sunxi: Fix gate indexing for sun6i-a31-apb0-gates
sun6i-a31-apb0-gates supports using clock-indices for holes between individual gates. However, the driver passes the number of gates registered in clk_data->clk_num, which of_clk_src_onecell_get uses to recognize the range of valid indices a consumer can use. This patch makes the driver pass the maximum gate index + 1, so of_clk_src_onecell_get does not complain about indices greater than gates registered. This was tested on the A23 SoC, which has a similar APB0 clock, but has holes for gates to removed IP blocks. Signed-off-by: Chen-Yu Tsai --- drivers/clk/sunxi/clk-sun6i-apb0-gates.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/clk/sunxi/clk-sun6i-apb0-gates.c b/drivers/clk/sunxi/clk-sun6i-apb0-gates.c index 44cd27c..b342f2a 100644 --- a/drivers/clk/sunxi/clk-sun6i-apb0-gates.c +++ b/drivers/clk/sunxi/clk-sun6i-apb0-gates.c @@ -25,6 +25,7 @@ static int sun6i_a31_apb0_gates_clk_probe(struct platform_device *pdev) void __iomem *reg; int gate_id; int ngates; + int gate_max = 0; int i; r = platform_get_resource(pdev, IORESOURCE_MEM, 0); @@ -72,9 +73,12 @@ static int sun6i_a31_apb0_gates_clk_probe(struct platform_device *pdev) reg, gate_id, 0, NULL); WARN_ON(IS_ERR(clk_data->clks[gate_id])); + + if (gate_id > gate_max) + gate_max = gate_id; } - clk_data->clk_num = ngates; + clk_data->clk_num = gate_max + 1; return of_clk_add_provider(np, of_clk_src_onecell_get, clk_data); } -- 2.0.0.rc2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/22] serial: 8250_dw: Add optional reset control support
The Allwinner A31 and A23 SoCs have a reset controller
maintaining the UART in reset by default.
This patch adds optional reset support to the driver.
Signed-off-by: Chen-Yu Tsai
---
Documentation/devicetree/bindings/serial/snps-dw-apb-uart.txt | 1 +
drivers/tty/serial/8250/8250_dw.c | 10 ++
2 files changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.txt
b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.txt
index f13f1c5..cb9af84 100644
--- a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.txt
+++ b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.txt
@@ -7,6 +7,7 @@ Required properties:
- clock-frequency : the input clock frequency for the UART.
Optional properties:
+- resets : phandle to the parent reset controller.
- reg-shift : quantity to shift the register offsets by. If this property is
not present then the register offsets are not shifted.
- reg-io-width : the size (in bytes) of the IO accesses that should be
diff --git a/drivers/tty/serial/8250/8250_dw.c
b/drivers/tty/serial/8250/8250_dw.c
index ed31135..d0c6d080 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include
#include
@@ -59,6 +60,7 @@ struct dw8250_data {
int last_mcr;
int line;
struct clk *clk;
+ struct reset_control*rst;
struct uart_8250_dmadma;
};
@@ -259,6 +261,8 @@ static int dw8250_probe_of(struct uart_port *p,
if (!of_property_read_u32(np, "reg-shift", &val))
p->regshift = val;
+ data->rst = devm_reset_control_get_optional(p->dev, NULL);
+
/* clock got configured through clk api, all done */
if (p->uartclk)
return 0;
@@ -362,6 +366,9 @@ static int dw8250_probe(struct platform_device *pdev)
return -ENODEV;
}
+ if (!IS_ERR_OR_NULL(data->rst))
+ reset_control_deassert(data->rst);
+
data->line = serial8250_register_8250_port(&uart);
if (data->line < 0)
return data->line;
@@ -382,6 +389,9 @@ static int dw8250_remove(struct platform_device *pdev)
serial8250_unregister_port(data->line);
+ if (!IS_ERR_OR_NULL(data->rst))
+ reset_control_assert(data->rst);
+
if (!IS_ERR(data->clk))
clk_disable_unprepare(data->clk);
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/22] ARM: sun6i: DT: Add PLL6 multiple outputs
PLL6 on sun6i has multiple outputs, just like the other sunxi platforms.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/boot/dts/sun6i-a31.dtsi | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 0f4ea49..d9643fa 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -95,11 +95,11 @@
};
pll6: clk@01c20028 {
- #clock-cells = <0>;
+ #clock-cells = <1>;
compatible = "allwinner,sun6i-a31-pll6-clk";
reg = <0x01c20028 0x4>;
clocks = <&osc24M>;
- clock-output-names = "pll6";
+ clock-output-names = "pll6_other", "pll6";
};
cpu: cpu@01c20050 {
@@ -129,7 +129,7 @@
#clock-cells = <0>;
compatible = "allwinner,sun6i-a31-ahb1-mux-clk";
reg = <0x01c20054 0x4>;
- clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6>;
+ clocks = <&osc32k>, <&osc24M>, <&axi>, <&pll6 0>;
clock-output-names = "ahb1_mux";
};
@@ -184,7 +184,7 @@
#clock-cells = <0>;
compatible = "allwinner,sun4i-a10-apb1-mux-clk";
reg = <0x01c20058 0x4>;
- clocks = <&osc32k>, <&osc24M>, <&pll6>, <&pll6>;
+ clocks = <&osc32k>, <&osc24M>, <&pll6 0>, <&pll6 0>;
clock-output-names = "apb2_mux";
};
@@ -211,7 +211,7 @@
#clock-cells = <0>;
compatible = "allwinner,sun4i-a10-mod0-clk";
reg = <0x01c20088 0x4>;
- clocks = <&osc24M>, <&pll6>;
+ clocks = <&osc24M>, <&pll6 0>;
clock-output-names = "mmc0";
};
@@ -219,7 +219,7 @@
#clock-cells = <0>;
compatible = "allwinner,sun4i-a10-mod0-clk";
reg = <0x01c2008c 0x4>;
- clocks = <&osc24M>, <&pll6>;
+ clocks = <&osc24M>, <&pll6 0>;
clock-output-names = "mmc1";
};
@@ -227,7 +227,7 @@
#clock-cells = <0>;
compatible = "allwinner,sun4i-a10-mod0-clk";
reg = <0x01c20090 0x4>;
- clocks = <&osc24M>, <&pll6>;
+ clocks = <&osc24M>, <&pll6 0>;
clock-output-names = "mmc2";
};
@@ -235,7 +235,7 @@
#clock-cells = <0>;
compatible = "allwinner,sun4i-a10-mod0-clk";
reg = <0x01c20094 0x4>;
- clocks = <&osc24M>, <&pll6>;
+ clocks = <&osc24M>, <&pll6 0>;
clock-output-names = "mmc3";
};
@@ -243,7 +243,7 @@
#clock-cells = <0>;
compatible = "allwinner,sun4i-a10-mod0-clk";
reg = <0x01c200a0 0x4>;
- clocks = <&osc24M>, <&pll6>;
+ clocks = <&osc24M>, <&pll6 0>;
clock-output-names = "spi0";
};
@@ -251,7 +251,7 @@
#clock-cells = <0>;
compatible = "allwinner,sun4i-a10-mod0-clk";
reg = <0x01c200a4 0x4>;
- clocks = <&osc24M>, <&pll6>;
+ clocks = <&osc24M>, <&pll6 0>;
clock-output-names = "spi1";
};
@@ -259,7 +259,7 @@
#clock-cells = <0>;
compatible = "allwinner,sun4i-a10-mod0-clk";
reg = <0x01c200a8 0x4>;
- clocks = <&osc24M>, <&pll6>;
+ clocks = <&osc24M>, <&pll6 0>;
clock-output-names = "spi2";
};
@@ -267,7 +267,7 @@
#clock-cells = <0>;
compatible = "allwinner,sun4i-a10-mod0-clk";
reg = <0x01c200ac 0x4>;
- clocks = <&osc24M>, <&pll6>;
+ clocks = <&osc24M>, <&pll6 0>;
clock-output-names = "spi3";
};
@@ -695,7 +695,7 @@
ar100: ar100_clk {
compatible = "allwinner,sun6i-a31-ar100-clk";
#clock-cells = <0>;
- clocks = <&osc32k>, <&osc24M>, <&pll6>, <&pll6>;
+ clocks = <&osc32k>, <&osc24M>, <&pll6 0>,
<&pll6
[PATCH 20/22] ARM: sun8i: Add SMP support for the Allwinner A23
The A23 is a dual Cortex-A7. Add the logic to use the IPs used to
control the CPU configuration and the CPU power so that we can
bring up secondary CPUs at boot.
Signed-off-by: Chen-Yu Tsai
---
arch/arm/mach-sunxi/platsmp.c | 69 +++
1 file changed, 69 insertions(+)
diff --git a/arch/arm/mach-sunxi/platsmp.c b/arch/arm/mach-sunxi/platsmp.c
index c53077b..688faaf 100644
--- a/arch/arm/mach-sunxi/platsmp.c
+++ b/arch/arm/mach-sunxi/platsmp.c
@@ -121,3 +121,72 @@ struct smp_operations sun6i_smp_ops __initdata = {
.smp_boot_secondary = sun6i_smp_boot_secondary,
};
CPU_METHOD_OF_DECLARE(sun6i_smp, "allwinner,sun6i-a31", &sun6i_smp_ops);
+
+static void __init sun8i_smp_prepare_cpus(unsigned int max_cpus)
+{
+ struct device_node *node;
+
+ node = of_find_compatible_node(NULL, NULL, "allwinner,sun8i-a23-prcm");
+ if (!node) {
+ pr_err("Missing A23 PRCM node in the device tree\n");
+ return;
+ }
+
+ prcm_membase = of_iomap(node, 0);
+ if (!prcm_membase) {
+ pr_err("Couldn't map A23 PRCM registers\n");
+ return;
+ }
+
+ node = of_find_compatible_node(NULL, NULL,
+ "allwinner,sun8i-a23-cpuconfig");
+ if (!node) {
+ pr_err("Missing A23 CPU config node in the device tree\n");
+ return;
+ }
+
+ cpucfg_membase = of_iomap(node, 0);
+ if (!cpucfg_membase)
+ pr_err("Couldn't map A23 CPU config registers\n");
+
+}
+
+static int sun8i_smp_boot_secondary(unsigned int cpu,
+ struct task_struct *idle)
+{
+ u32 reg;
+
+ if (!(prcm_membase && cpucfg_membase))
+ return -EFAULT;
+
+ spin_lock(&cpu_lock);
+
+ /* Set CPU boot address */
+ writel(virt_to_phys(secondary_startup),
+ cpucfg_membase + CPUCFG_PRIVATE0_REG);
+
+ /* Assert the CPU core in reset */
+ writel(0, cpucfg_membase + CPUCFG_CPU_RST_CTRL_REG(cpu));
+
+ /* Assert the L1 cache in reset */
+ reg = readl(cpucfg_membase + CPUCFG_GEN_CTRL_REG);
+ writel(reg & ~BIT(cpu), cpucfg_membase + CPUCFG_GEN_CTRL_REG);
+
+ /* Clear CPU power-off gating */
+ reg = readl(prcm_membase + PRCM_CPU_PWROFF_REG);
+ writel(reg & ~BIT(cpu), prcm_membase + PRCM_CPU_PWROFF_REG);
+ mdelay(1);
+
+ /* Deassert the CPU core reset */
+ writel(3, cpucfg_membase + CPUCFG_CPU_RST_CTRL_REG(cpu));
+
+ spin_unlock(&cpu_lock);
+
+ return 0;
+}
+
+struct smp_operations sun8i_smp_ops __initdata = {
+ .smp_prepare_cpus = sun8i_smp_prepare_cpus,
+ .smp_boot_secondary = sun8i_smp_boot_secondary,
+};
+CPU_METHOD_OF_DECLARE(sun8i_smp, "allwinner,sun8i-a23", &sun8i_smp_ops);
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 19/22] ARM: sunxi: Add earlyprintk support using R_UART (sun6i/sun8i)
sun6i/sun8i have a UART in the RTC block group, which can be used as an early console. This is most useful on sun8i as UART0 is muxed with MMC0, which is not available if we boot from MMC. Signed-off-by: Chen-Yu Tsai --- arch/arm/Kconfig.debug | 10 ++ 1 file changed, 10 insertions(+) diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug index eab8ecb..9e22708 100644 --- a/arch/arm/Kconfig.debug +++ b/arch/arm/Kconfig.debug @@ -694,6 +694,14 @@ choice Say Y here if you want kernel low-level debugging support on Allwinner A1X based platforms on the UART1. + config DEBUG_SUNXI_R_UART + bool "Kernel low-level debugging messages via sunXi R_UART" + depends on ARCH_SUNXI + select DEBUG_UART_8250 + help + Say Y here if you want kernel low-level debugging support + on Allwinner A31 based platforms on the R_UART. + config TEGRA_DEBUG_UART_AUTO_ODMDATA bool "Kernel low-level debugging messages via Tegra UART via ODMDATA" depends on ARCH_TEGRA @@ -1007,6 +1015,7 @@ config DEBUG_UART_PHYS default 0x01c28400 if DEBUG_SUNXI_UART1 default 0x01d0c000 if DEBUG_DAVINCI_DA8XX_UART1 default 0x01d0d000 if DEBUG_DAVINCI_DA8XX_UART2 + default 0x01f02800 if DEBUG_SUNXI_R_UART default 0x02530c00 if DEBUG_KEYSTONE_UART0 default 0x02531000 if DEBUG_KEYSTONE_UART1 default 0x03010fe0 if ARCH_RPC @@ -1072,6 +1081,7 @@ config DEBUG_UART_VIRT default 0xf160 if ARCH_INTEGRATOR default 0xf1c28000 if DEBUG_SUNXI_UART0 default 0xf1c28400 if DEBUG_SUNXI_UART1 + default 0xf1f02800 if DEBUG_SUNXI_R_UART default 0xf210 if DEBUG_PXA_UART1 default 0xf409 if ARCH_LPC32XX default 0xf420 if ARCH_GEMINI -- 2.0.0.rc2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net] bridge: notify user space of fdb port change
(2014/05/23 13:59), Jon Maxwell wrote:
...
> Makita-san,
>
> I recoded this using your idea and ran it through a reproducer.
> It work fine. After some more consideration I agree that
> setting fdb->dst = source is only required when source != fdb->dst.
>
> Thanks for your suggestions. This is the revised patch. It should
> retain the original behaviour except for the notify after the fdb update.
>
> Please let me know if you have any further input?
I have no more comments except for style problems (bracket position,
indentation, type mismatch).
thank you for rewriting :)
Thanks,
Toshiaki Makita
>
> $ diff -Naur br_fdb.c br_fdb.c.patch
> --- br_fdb.c2014-05-17 12:43:23.346319609 +1000
> +++ br_fdb.c.patch2014-05-17 16:54:46.280235728 +1000
> @@ -487,6 +487,7 @@
> {
> struct hlist_head *head = &br->hash[br_mac_hash(addr, vid)];
> struct net_bridge_fdb_entry *fdb;
> +bool fdb_modified = 0;
>
> /* some users want to always flood. */
> if (hold_time(br) == 0)
> @@ -507,10 +508,16 @@
> source->dev->name);
> } else {
> /* fastpath: update of existing entry */
> -fdb->dst = source;
> +if (unlikely(source != fdb->dst))
> +{
> +fdb->dst = source;
> +fdb_modified = 1;
> +}
> fdb->updated = jiffies;
> if (unlikely(added_by_user))
> fdb->added_by_user = 1;
> +if (unlikely(fdb_modified))
> +fdb_notify(br, fdb, RTM_NEWNEIGH);
> }
> } else {
> spin_lock(&br->hash_lock);
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the tip tree with the arm64 tree
On Fri, May 23, 2014 at 07:28:44AM +0100, Stephen Rothwell wrote: > diff --cc arch/arm64/include/asm/thread_info.h > index 9c086c63f911,7b8e3a2a00fb.. > --- a/arch/arm64/include/asm/thread_info.h > +++ b/arch/arm64/include/asm/thread_info.h > @@@ -103,12 -99,7 +102,11 @@@ static inline struct thread_info *curre > #define TIF_SIGPENDING 0 > #define TIF_NEED_RESCHED1 > #define TIF_NOTIFY_RESUME 2 /* callback before returning to user */ > +#define TIF_FOREIGN_FPSTATE 3 /* CPU's FP state is not current's */ > #define TIF_SYSCALL_TRACE 8 > +#define TIF_SYSCALL_AUDIT 9 > +#define TIF_SYSCALL_TRACEPOINT 10 > +#define TIF_SECCOMP 11 > - #define TIF_POLLING_NRFLAG 16 > #define TIF_MEMDIE 18 /* is terminating due to OOM killer */ > #define TIF_FREEZE 19 > #define TIF_RESTORE_SIGMASK 20 It looks fine, thanks. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the pwm tree with the leds tree
On 23/05/2014 at 09:19:41 +0200, Thierry Reding wrote :
> On Thu, May 22, 2014 at 07:24:23PM +1000, Stephen Rothwell wrote:
> > Hi Thierry,
> >
> > Today's linux-next merge of the pwm tree got a conflict in
> > drivers/leds/leds-pwm.c between commit 5f7b03dc2ab5 ("leds: leds-pwm:
> > provide a common function to setup a single led-pwm device") from the
> > leds tree and commit 81225bed3273 ("leds: leds-pwm: retrieve configured
> > PWM period") from the pwm tree.
> >
> > I fixed it up (I think - see below) and can carry the fix as necessary
> > (no action is required).
>
> The resolution below looks good to me. Thanks!
>
> Alexandre, Bryan, as far as I can tell there are no dependencies between
> this patch and the rest of the series that Alexandre sent, so perhaps it
> would be a better idea to take this particular patch via Bryan's leds
> tree?
>
> Then again the resolution looks like something that Linus can reasonably
> handle, so maybe things are fine as-is.
>
I'm fine with either solution, tell me if you want me to rebase my
patch.
--
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: build failure after merge of the mmc tree
On 05/23/2014 07:32 AM, Stephen Rothwell wrote:
After merging the mmc tree, today's linux-next build (arm multi_v7_defconfig)
failed like this:
drivers/mmc/host/sdhci-dove.c: In function 'sdhci_dove_carddetect_irq':
drivers/mmc/host/sdhci-dove.c:42:24: error: 'struct sdhci_host' has no member
named 'card_tasklet'
Caused by commit 3560db8e247a ("mmc: sdhci: push card_tasklet into
threaded irq handler").
I have used the mmc tree from next-20140522 for today.
Stephen,
I received that build failure yesterday for mmc-next. Patch sent to
Chris and Ulf. Should be fixed as soon as it hits mmc-next.
Sebastian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 21/49] media: davinci: vpif_display: use SIMPLE_DEV_PM_OPS
On 05/16/2014 03:33 PM, Lad, Prabhakar wrote:
> From: "Lad, Prabhakar"
>
> this patch uses SIMPLE_DEV_PM_OPS, and drops unneeded members
> from io_usrs, usrs and makes use of vb2 helepers instead.
>
> Signed-off-by: Lad, Prabhakar
> ---
> drivers/media/platform/davinci/vpif_display.c | 64
> -
> drivers/media/platform/davinci/vpif_display.h |4 --
> 2 files changed, 30 insertions(+), 38 deletions(-)
>
> diff --git a/drivers/media/platform/davinci/vpif_display.c
> b/drivers/media/platform/davinci/vpif_display.c
> index 401d03a..81d955a 100644
> --- a/drivers/media/platform/davinci/vpif_display.c
> +++ b/drivers/media/platform/davinci/vpif_display.c
> @@ -1124,10 +1124,8 @@ static int vpif_probe_complete(void)
> for (j = 0; j < VPIF_DISPLAY_MAX_DEVICES; j++) {
> ch = vpif_obj.dev[j];
> /* Initialize field of the channel objects */
> - atomic_set(&ch->usrs, 0);
> for (k = 0; k < VPIF_NUMOBJECTS; k++) {
> common = &ch->common[k];
> - common->io_usrs = 0;
> spin_lock_init(&common->irqlock);
> mutex_init(&common->lock);
> common->set_addr = NULL;
> @@ -1371,7 +1369,7 @@ static int vpif_remove(struct platform_device *device)
> return 0;
> }
>
> -#ifdef CONFIG_PM
> +#ifdef CONFIG_PM_SLEEP
> static int vpif_suspend(struct device *dev)
> {
> struct common_obj *common;
> @@ -1382,18 +1380,20 @@ static int vpif_suspend(struct device *dev)
> /* Get the pointer to the channel object */
> ch = vpif_obj.dev[i];
> common = &ch->common[VPIF_VIDEO_INDEX];
> +
> + if (!vb2_is_streaming(&common->buffer_queue))
> + continue;
The use of vb2_is_streaming here is not correct. It is possible to call STREAMON
without having any buffers queued. So vb2_is_streaming() can return true without
start_streaming() having been called. Only after at least one buffer has been
queued will start_streaming be called.
So this code will fail if you call STREAMON without any buffers queued and
then suspend and resume. The resume callback will start the DMA without having
proper DMA pointers set up. Probably not a good idea.
The fix is to check the vb2_queue->start_streaming_called flag. I think we
need a vb2_start_streaming_called() inline function as that's a bit cleaner
than checking that flag directly.
Regards,
Hans
> +
> mutex_lock(&common->lock);
> - if (atomic_read(&ch->usrs) && common->io_usrs) {
> - /* Disable channel */
> - if (ch->channel_id == VPIF_CHANNEL2_VIDEO) {
> - enable_channel2(0);
> - channel2_intr_enable(0);
> - }
> - if (ch->channel_id == VPIF_CHANNEL3_VIDEO ||
> - ycmux_mode == 2) {
> - enable_channel3(0);
> - channel3_intr_enable(0);
> - }
> + /* Disable channel */
> + if (ch->channel_id == VPIF_CHANNEL2_VIDEO) {
> + enable_channel2(0);
> + channel2_intr_enable(0);
> + }
> + if (ch->channel_id == VPIF_CHANNEL3_VIDEO ||
> + ycmux_mode == 2) {
> + enable_channel3(0);
> + channel3_intr_enable(0);
> }
> mutex_unlock(&common->lock);
> }
> @@ -1412,18 +1412,20 @@ static int vpif_resume(struct device *dev)
> /* Get the pointer to the channel object */
> ch = vpif_obj.dev[i];
> common = &ch->common[VPIF_VIDEO_INDEX];
> +
> + if (!vb2_is_streaming(&common->buffer_queue))
> + continue;
> +
> mutex_lock(&common->lock);
> - if (atomic_read(&ch->usrs) && common->io_usrs) {
> - /* Enable channel */
> - if (ch->channel_id == VPIF_CHANNEL2_VIDEO) {
> - enable_channel2(1);
> - channel2_intr_enable(1);
> - }
> - if (ch->channel_id == VPIF_CHANNEL3_VIDEO ||
> - ycmux_mode == 2) {
> - enable_channel3(1);
> - channel3_intr_enable(1);
> - }
> + /* Enable channel */
> + if (ch->channel_id == VPIF_CHANNEL2_VIDEO) {
> + enable_channel2(1);
> + channel2_intr_enable(1);
> + }
> + if (ch->channel_id == VPIF_CHANNEL3_VIDEO ||
> + ycmux_mode == 2) {
> + enable_channel3(1);
> + channel3_intr_enable(1);
>
Re: [PATCH v5 3/6] seccomp: introduce writer locking
On Thu, May 22, 2014 at 04:05:33PM -0700, Kees Cook wrote: > Normally, task_struct.seccomp.filter is only ever read or modified by > the task that owns it (current). This property aids in fast access > during system call filtering as read access is lockless. > > Updating the pointer from another task, however, opens up race > conditions. To allow cross-task filter pointer updates, writes to the > seccomp fields are now protected by a spinlock. Read access remains > lockless because pointer updates themselves are atomic. However, writes > (or cloning) often entail additional checking (like maximum instruction > counts) which require locking to perform safely. > > In the case of cloning threads, the child is invisible to the system > until it enters the task list. To make sure a child can't be cloned > from a thread and left in a prior state, seccomp duplication is moved > under the tasklist_lock. Then parent and child are certain have the same > seccomp state when they exit the lock. > So I'm a complete noob on the whole seccomp thing, so maybe this is a silly question, but.. what about object lifetimes? Looking at put_seccomp_filter() it explicitly takes a tsk pointer, suggesting one can call it on !current. And while it does a dec_and_test on the object itself, run_filter() does nothing with refcounts, and therefore can be touching dead memory. pgpeN81CQhfl3.pgp Description: PGP signature
[GIT PULL v2] mfd/gpio: New pull request with irq_base removed
> > drivers/mfd/stmpe.c: In function 'stmpe_irq_init':
> > drivers/mfd/stmpe.c:1000:15: error: 'struct stmpe' has no member named
> > 'irq_base'
> >base = stmpe->irq_base;
> >^
> >
> > Caused by commit 3ba1d516d5fe ("mfd: stmpe: root out static GPIO and
> > IRQ assignments").
>
> Some mishap in merging these patches I think. I don't have that
> line in my branch with the latest patches,
I'm not sure that's true:
`git grep irq_base linusw-next/stmpe-for-lee -- drivers/mfd/stmpe.c`
linusw-next/stmpe-for-lee:drivers/mfd/stmpe.c: base = stmpe->irq_base;
>I'll get the proper versions to Lee somehow.
I've fixed up the branch and re-pushed:
The following changes since commit 89ca3b881987f5a4be4c5dbaa7f0df12bbdde2fd:
Linux 3.15-rc4 (2014-05-04 18:14:42 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git
tags/ib-mfd-gpio-v3.16
for you to fetch changes up to 9e9dc7d9597bd6881b3e7ae6ae3d710319605c47:
mfd: stmpe: root out static GPIO and IRQ assignments (2014-05-23 09:41:01
+0100)
Immutable branch between MFD and GPIO due for the v3.16 merge window.
Linus Walleij (4):
mfd: stmpe: mask off unused blocks properly
mfd: stmpe: Probe properly from the Device Tree
mfd: stmpe: add optional regulators
mfd: stmpe: root out static GPIO and IRQ assignments
drivers/gpio/gpio-stmpe.c | 18 +-
drivers/mfd/Kconfig | 1 +
drivers/mfd/stmpe-i2c.c | 30 +-
drivers/mfd/stmpe.c | 33 -
drivers/mfd/stmpe.h | 2 +-
include/linux/mfd/stmpe.h | 19 +--
6 files changed, 69 insertions(+), 34 deletions(-)
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: skbuff truesize incorrect.
From: Eric Dumazet > On Thu, 2014-05-22 at 20:07 +0100, Jim Baxter wrote: > > > > > I have been investigating a network issue with bursts of network traffic > > over USB CDC-NCM, the issue is that the kernel is dropping packets > > because sk_rcvqueues_full() returns true due to skb2->truesize is always > > 32960 instead of SKB_TRUESIZE(skb2->len) which is about 1800. > > > > The code I am trying to fix is this code below, it is splitting a set of > > multiple network packets compressed into a single 16k packet into > > individual skb's and sending them up the network stack. > > if skb are allocated with 16k = 16384 bytes, adding the struct > skb_shared_info overhead and rounding up to power of two gives 32768 > bytes. > > Chances to be able to allocate 32KB contiguous memory are slim after a > while. > > I would set rx_max (rx_urb_size) to SKB_MAX_HEAD(0) so that you do not > use high order allocations. > > What is the exact 'overhead' using ~4K instead of 16K exactly on this > hardware ? Many of the usb ethernet drivers have the same issue. The hardware will put multiple ethernet frames into a single USB bulk data message. To handle this the driver generates a URB that is (hopefully) long enough for the longest USB message (typically 32k is assumed to be enough). The URB that usb_net generated have the data in a linear skb - which then has a large 'truesize'. Since USB bulk data are terminated by a short fragment there is actually no need for the URB be long enough for the full message. Provided the URB are multiples of the USB message size (1k for USB 3) the message can be received into multiple URB - the driver just has to be willing to merge URB buffers (as well as split them) when generating the ethernet frames. What the driver needs to do us allocate URB with 2k (or 4k) buffers and only allocate the skb when processing the receive data. Unfortunately this is a major rework of usb_net.c Note that some of the usb ethernet drivers allocate large skb then lie about the truesize. David
[PATCH 4/4] tile: Update comments for generic idle conversion
As of commit 0dc8153cfebac68c9523b8852b14f10b31209f08 ("tile: Use generic
idle loop"), this applies to arch_cpu_idle() instead of cpu_idle().
Signed-off-by: Geert Uytterhoeven
Cc: Chris Metcalf
---
arch/tile/include/asm/thread_info.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/tile/include/asm/thread_info.h
b/arch/tile/include/asm/thread_info.h
index 729aa107f64e..80ba7d40ecc0 100644
--- a/arch/tile/include/asm/thread_info.h
+++ b/arch/tile/include/asm/thread_info.h
@@ -94,7 +94,7 @@ register unsigned long stack_pointer __asm__("sp");
/* Sit on a nap instruction until interrupted. */
extern void smp_nap(void);
-/* Enable interrupts racelessly and nap forever: helper for cpu_idle(). */
+/* Enable interrupts racelessly and nap forever: helper for arch_cpu_idle(). */
extern void _cpu_idle(void);
#else /* __ASSEMBLY__ */
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] powerpc: Update comments for generic idle conversion
As of commit 799fef06123f86ff69cf754f996219e6ad1678f8 ("powerpc: Use
generic idle loop"), this applies to arch_cpu_idle() instead of cpu_idle().
Signed-off-by: Geert Uytterhoeven
Cc: Benjamin Herrenschmidt
Cc: linuxppc-...@lists.ozlabs.org
---
arch/powerpc/kernel/irq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index ca1cd7459c4a..248ee7e5bebd 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -304,7 +304,7 @@ void notrace restore_interrupts(void)
* being re-enabled and generally sanitized the lazy irq state,
* and in the latter case it will leave with interrupts hard
* disabled and marked as such, so the local_irq_enable() call
- * in cpu_idle() will properly re-enable everything.
+ * in arch_cpu_idle() will properly re-enable everything.
*/
bool prep_irq_for_idle(void)
{
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] cpuidle: Remove remaining cpu_idle() references
Hi Thomas,
After all architectures were converted to the generic idle framework,
commit d190e8195b90bc1e65c494fe08e54e9e581bfd16 ("idle: Remove
GENERIC_IDLE_LOOP config switch") removed the last caller of cpu_idle().
This series removes the remaining references to the no-longer existing
cpu_idle() function.
There are still a few references left, but these refer to the generic
mechanism, not to the C function.
- [PATCH 1/4] idle: Remove cpu_idle() forward declarations
- [PATCH 2/4] cris: Update comments for generic idle conversion
- [PATCH 3/4] powerpc: Update comments for generic idle conversion
- [PATCH 4/4] tile: Update comments for generic idle conversion
Please apply. Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] idle: Remove cpu_idle() forward declarations
After all architectures were converted to the generic idle framework,
commit d190e8195b90bc1e65c494fe08e54e9e581bfd16 ("idle: Remove
GENERIC_IDLE_LOOP config switch") removed the last caller of cpu_idle().
The forward declarations in header files were forgotten.
Signed-off-by: Geert Uytterhoeven
---
include/linux/cpu.h | 1 -
include/linux/smp.h | 2 --
2 files changed, 3 deletions(-)
diff --git a/include/linux/cpu.h b/include/linux/cpu.h
index 81887120395c..95978ad7fcdd 100644
--- a/include/linux/cpu.h
+++ b/include/linux/cpu.h
@@ -256,7 +256,6 @@ enum cpuhp_state {
};
void cpu_startup_entry(enum cpuhp_state state);
-void cpu_idle(void);
void cpu_idle_poll_ctrl(bool enable);
diff --git a/include/linux/smp.h b/include/linux/smp.h
index 633f5edd7470..34347f26be9b 100644
--- a/include/linux/smp.h
+++ b/include/linux/smp.h
@@ -13,8 +13,6 @@
#include
#include
-extern void cpu_idle(void);
-
typedef void (*smp_call_func_t)(void *info);
struct call_single_data {
struct llist_node llist;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] cris: Update comments for generic idle conversion
As of commit 8dc7c5ecd8d0f739728d844ee794c4fae169f9c2 ("cris: Use generic
idle loop"), cris no longer provides cpu_idle().
- On cris-v10, etrax_gpio_wake_up_check() is called from
default_idle() instead of cpu_idle(),
- On cris-v32, etrax_gpio_wake_up_check() is not called from
default_idle(), so remove this (copy-and-paste?) part.
Signed-off-by: Geert Uytterhoeven
Cc: Jesper Nilsson
Cc: linux-cris-ker...@axis.com
---
arch/cris/arch-v10/drivers/gpio.c | 4 ++--
arch/cris/arch-v32/drivers/mach-fs/gpio.c | 6 +-
2 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/arch/cris/arch-v10/drivers/gpio.c
b/arch/cris/arch-v10/drivers/gpio.c
index f4374bae4fb4..64285e0d3481 100644
--- a/arch/cris/arch-v10/drivers/gpio.c
+++ b/arch/cris/arch-v10/drivers/gpio.c
@@ -833,8 +833,8 @@ static int __init gpio_init(void)
printk(KERN_INFO "ETRAX 100LX GPIO driver v2.5, (c) 2001-2008 "
"Axis Communications AB\n");
/* We call etrax_gpio_wake_up_check() from timer interrupt and
-* from cpu_idle() in kernel/process.c
-* The check in cpu_idle() reduces latency from ~15 ms to ~6 ms
+* from default_idle() in kernel/process.c
+* The check in default_idle() reduces latency from ~15 ms to ~6 ms
* in some tests.
*/
res = request_irq(TIMER0_IRQ_NBR, gpio_poll_timer_interrupt,
diff --git a/arch/cris/arch-v32/drivers/mach-fs/gpio.c
b/arch/cris/arch-v32/drivers/mach-fs/gpio.c
index 9e54273af0ca..009f4ee1bd09 100644
--- a/arch/cris/arch-v32/drivers/mach-fs/gpio.c
+++ b/arch/cris/arch-v32/drivers/mach-fs/gpio.c
@@ -958,11 +958,7 @@ gpio_init(void)
printk(KERN_INFO "ETRAX FS GPIO driver v2.5, (c) 2003-2007 "
"Axis Communications AB\n");
- /* We call etrax_gpio_wake_up_check() from timer interrupt and
-* from cpu_idle() in kernel/process.c
-* The check in cpu_idle() reduces latency from ~15 ms to ~6 ms
-* in some tests.
-*/
+ /* We call etrax_gpio_wake_up_check() from timer interrupt */
if (request_irq(TIMER0_INTR_VECT, gpio_poll_timer_interrupt,
IRQF_SHARED, "gpio poll", &alarmlist))
printk(KERN_ERR "timer0 irq for gpio\n");
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] sound branch of STMPE cleanups
On Fri, May 23, 2014 at 10:32 AM, Lee Jones wrote: > Nope, this branch is broken too. I don't think this is a merge error, > I think it's programmer error (even the greats make mistakes =:-) ). Yeah you're right :-( :-( Sorry for the mess. > In the mean time, it might be worth you looking at your build system, > as it seems to be overlooking drivers/mfd/stmpe.c. This indeed seems to be the problem. Thanks for covering up my stupid mistakes, I owe you one. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: skbuff truesize incorrect.
> But although the problem is the same, I believe the driver in question > isn't the one I have been looking at recently. The posted code snippet > was from the NCM gadget driver (drivers/usb/gadget/f_ncm.c), isn't that > right Jim? Yes this is the NCM Gadget driver. > > Yes, judging by this discussion I guess we should unconditionally copy > instead of cloning in these drivers. We'll always have bad > payload/truesize ratio for cloned skbs, often less than 1/10 even for > max size payload. > > Actually, I thought we already did copy in the host cdc_ncm driver. But > I was wrong. I was thinking of the cdc_mbim driver (which is different > enough to have its own implementation of this part of the rx code). The > cdc_ncm driver is cloning and the cdc_mbim driver is copying. So we're > not even consistent... > > I'll create and test a patch for the cdc_ncm host driver unless someone > else wants to do that. I haven't really played with the gadget driver > before, so I'd prefer if someone knowing it (Jim maybe?) could take care > of it. If not, then I can always make an attempt using dummy_hcd to > test it. I can create a patch for the host driver, I will issue the gadget patch first to resolve any issues, the fix would be similar. > > BTW, wrt the data rates: These drivers are USB class drivers and we > should really think of *all* possible rates, even future ones. This is > not limited to 480 Mbps USB2. AFAICS, there isn't anything preventing > the gadget driver from being used with e.g. a USB3380 controller to > create a 5 Gbps NCM device. I'm sure the future will bring us even > faster USB devices. The drivers will be the same. Which is sort of > beautiful and scaring at the same time :-) > > But I assume the bad payload/truesize ratio is the most important factor > here, so we should still copy? I will test the copy implementation for any performance impact. Jim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Subject: Build regressions/improvements in v3.15-rc6
Below is the list of build error/warning regressions/improvements in v3.15-rc6[1] compared to v3.14[2]. Summarized: - build errors: +5/-2 - build warnings: +109/-112 JFYI, when comparing v3.15-rc6[1] to v3.15-rc5[3], the summaries are: - build errors: +1/-3 - build warnings: +31/-37 As I haven't mastered kup yet, there's no verbose summary at http://www.kernel.org/pub/linux/kernel/people/geert/linux-log/v3.15-rc6.summary.gz Happy fixing! ;-) Thanks to the linux-next team for providing the build service. [1] http://kisskb.ellerman.id.au/kisskb/head/7497/ (all 119 configs) [2] http://kisskb.ellerman.id.au/kisskb/head/7320/ (all 119 configs) [3] http://kisskb.ellerman.id.au/kisskb/head/7468/ (all 119 configs) *** ERRORS *** 5 regressions: + /scratch/kisskb/src/arch/powerpc/platforms/powernv/setup.c: error: implicit declaration of function 'get_hard_smp_processor_id' [-Werror=implicit-function-declaration]: => 179:4 + /scratch/kisskb/src/arch/um/os-Linux/mem.c: error: 'TMPFS_MAGIC' undeclared (first use in this function): => 31 + /scratch/kisskb/src/arch/um/os-Linux/mem.c: error: (Each undeclared identifier is reported only once: => 31 + /scratch/kisskb/src/arch/um/os-Linux/mem.c: error: for each function it appears in.): => 31 + /scratch/kisskb/src/arch/um/os-Linux/mem.c: error: linux/magic.h: No such file or directory: => 16:25 2 improvements: - error: No rule to make target include/config/auto.conf: N/A => - error: vsprintf.c: relocation truncated to fit: R_AVR32_9UW_PCREL against `.text'+bc8: (.text+0x9c2) => *** WARNINGS *** 109 regressions: + /scratch/kisskb/src/arch/sh/kernel/cpu/sh3/../../entry-common.S: Warning: overflow in branch to syscall_exit_work; converted into longer instruction sequence: 376 => 383, 380 + /scratch/kisskb/src/arch/sh/kernel/cpu/sh4/../sh3/../../entry-common.S: Warning: overflow in branch to syscall_exit_work; converted into longer instruction sequence: 376 => 383, 380 + /scratch/kisskb/src/arch/sh/math-emu/math.c: warning: 'ieee_fpe_handler' defined but not used [-Wunused-function]: => 505:12 + /scratch/kisskb/src/drivers/char/random.c: warning: 'arch_random_refill' uses dynamic stack allocation [enabled by default]: => 1329:1 + /scratch/kisskb/src/drivers/gpio/gpio-pch.c: warning: 'pch_gpio_restore_reg_conf' defined but not used [-Wunused-function]: => 193:13 + /scratch/kisskb/src/drivers/gpio/gpio-pch.c: warning: 'pch_gpio_save_reg_conf' defined but not used [-Wunused-function]: => 176:13 + /scratch/kisskb/src/drivers/gpu/drm/bochs/bochs_drv.c: warning: 'bochs_pm_resume' defined but not used [-Wunused-function]: => 117:12 + /scratch/kisskb/src/drivers/gpu/drm/bochs/bochs_drv.c: warning: 'bochs_pm_suspend' defined but not used [-Wunused-function]: => 100:12 + /scratch/kisskb/src/drivers/gpu/drm/cirrus/cirrus_drv.c: warning: 'cirrus_pm_resume' defined but not used [-Wunused-function]: => 96:12 + /scratch/kisskb/src/drivers/gpu/drm/cirrus/cirrus_drv.c: warning: 'cirrus_pm_suspend' defined but not used [-Wunused-function]: => 79:12 + /scratch/kisskb/src/drivers/gpu/drm/i915/i915_cmd_parser.c: warning: format '%td' expects argument of type 'ptrdiff_t', but argument 5 has type 'long unsigned int' [-Wformat]: => 405:4 + /scratch/kisskb/src/drivers/gpu/drm/radeon/r100.c: warning: 'crit_point_ff.full' may be used uninitialized in this function [-Wuninitialized]: => 3577:47 + /scratch/kisskb/src/drivers/gpu/drm/radeon/r100.c: warning: 'disp_drain_rate.full' may be used uninitialized in this function [-Wuninitialized]: => 3576:42 + /scratch/kisskb/src/drivers/infiniband/hw/cxgb4/cq.c: warning: 'hw_cqe' may be used uninitialized in this function [-Wuninitialized]: => 307:33, 303:21 + /scratch/kisskb/src/drivers/infiniband/hw/ehca/ehca_mrmw.c: warning: 'prev_pgaddr' may be used uninitialized in this function [-Wuninitialized]: => 1907:6 + /scratch/kisskb/src/drivers/input/misc/max8997_haptic.c: warning: ignoring return value of 'regulator_enable', declared with attribute warn_unused_result [-Wunused-result]: => 185:19 + /scratch/kisskb/src/drivers/md/dm-crypt.c: warning: 'crypt_iv_lmk_one.isra.8' uses dynamic stack allocation [enabled by default]: => 572:1 + /scratch/kisskb/src/drivers/md/dm-crypt.c: warning: 'crypt_iv_tcw_whitening.isra.7' uses dynamic stack allocation [enabled by default]: => 714:1 + /scratch/kisskb/src/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c: warning: passing argument 1 of 'bnx2x_vf_pci_dealloc' from incompatible pointer type [enabled by default]: => 13237:4 + /scratch/kisskb/src/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h: warning: 'return' with a value, in function returning void [enabled by default]: => 574:59 + /scratch/kisskb/src/drivers/net/ethernet/broadcom/bnx2x/bnx2x_sriov.h: warning: 'struct bnx2' declared inside parameter list [enabled by default]: => 574:48 + /scratch/kisskb/src/drivers/net/ethernet
[PATCH] extcon: palmas: Make of_device_id array const
Array of struct of_device_id may be be const as expected by
of_match_table field.
Signed-off-by: Krzysztof Kozlowski
Cc: Graeme Gregory
---
drivers/extcon/extcon-palmas.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/extcon/extcon-palmas.c b/drivers/extcon/extcon-palmas.c
index ddff2b72f0a8..eb59fe564fd1 100644
--- a/drivers/extcon/extcon-palmas.c
+++ b/drivers/extcon/extcon-palmas.c
@@ -273,7 +273,7 @@ static int palmas_usb_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(palmas_pm_ops, palmas_usb_suspend, palmas_usb_resume);
-static struct of_device_id of_palmas_match_tbl[] = {
+static const struct of_device_id of_palmas_match_tbl[] = {
{ .compatible = "ti,palmas-usb", },
{ .compatible = "ti,palmas-usb-vid", },
{ .compatible = "ti,twl6035-usb", },
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Subject: Build regressions/improvements in v3.15-rc6
On Fri, 23 May 2014, Geert Uytterhoeven wrote:
> JFYI, when comparing v3.15-rc6[1] to v3.15-rc5[3], the summaries are:
> - build errors: +1/-3
+ error: initramfs.c: undefined reference to `__stack_chk_guard': =>
.init.text+0x1528)
x86_64-randconfig
> [1] http://kisskb.ellerman.id.au/kisskb/head/7497/ (all 119 configs)
> [3] http://kisskb.ellerman.id.au/kisskb/head/7468/ (all 119 configs)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 06/14] mmc: mmci: Qcomm: Add 3 clock cycle delay after register write
On Thu, May 15, 2014 at 11:37 AM, wrote: > From: Srinivas Kandagatla > > Most of the Qcomm SD card controller registers must be updated to the MCLK > domain so subsequent writes to registers will be ignored until 3 clock cycles > have passed. > > This patch adds a 3 clock cycle delay required after writing to controller > registers on Qualcomm SOCs. Without this delay all the register writes are not > successful, resulting in not detecting cards. The write clock delay is > activated by setting up mclk_delayed_writes variable in variant data. > > Signed-off-by: Srinivas Kandagatla OK this is looking good. Reviewed-by: Linus Walleij Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 05/14] mmc: mmci: Add register read/write wrappers.
On Thu, May 15, 2014 at 11:36 AM, wrote: > From: Srinivas Kandagatla > > This patch adds wrappers for readl/writel functions used in the driver. The > reason for this wrappers is to accommodate SOCs like Qualcomm which has > requirement for delaying the write for few cycles when writing to its SD Card > Controller registers. > > Signed-off-by: Srinivas Kandagatla Acked-by: Linus Walleij Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] clk: samsung: Make of_device_id array const
Array of struct of_device_id may be be const as expected by
of_match_table field and of_find_matching_node_and_match() function.
Signed-off-by: Krzysztof Kozlowski
---
drivers/clk/samsung/clk-exynos4.c| 2 +-
drivers/clk/samsung/clk-exynos5250.c | 2 +-
drivers/clk/samsung/clk-exynos5420.c | 2 +-
drivers/clk/samsung/clk-exynos5440.c | 2 +-
drivers/clk/samsung/clk.c| 2 +-
drivers/clk/samsung/clk.h| 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/clk/samsung/clk-exynos4.c
b/drivers/clk/samsung/clk-exynos4.c
index b4f967210175..3463535dcc25 100644
--- a/drivers/clk/samsung/clk-exynos4.c
+++ b/drivers/clk/samsung/clk-exynos4.c
@@ -1070,7 +1070,7 @@ static void __init exynos4_clk_register_finpll(void)
}
-static struct of_device_id ext_clk_match[] __initdata = {
+static const struct of_device_id ext_clk_match[] __initconst = {
{ .compatible = "samsung,clock-xxti", .data = (void *)0, },
{ .compatible = "samsung,clock-xusbxti", .data = (void *)1, },
{},
diff --git a/drivers/clk/samsung/clk-exynos5250.c
b/drivers/clk/samsung/clk-exynos5250.c
index e7ee4420da81..0d97c69fde29 100644
--- a/drivers/clk/samsung/clk-exynos5250.c
+++ b/drivers/clk/samsung/clk-exynos5250.c
@@ -678,7 +678,7 @@ static struct samsung_pll_clock exynos5250_plls[nr_plls]
__initdata = {
VPLL_LOCK, VPLL_CON0, NULL),
};
-static struct of_device_id ext_clk_match[] __initdata = {
+static const struct of_device_id ext_clk_match[] __initconst = {
{ .compatible = "samsung,clock-xxti", .data = (void *)0, },
{ },
};
diff --git a/drivers/clk/samsung/clk-exynos5420.c
b/drivers/clk/samsung/clk-exynos5420.c
index 60b26819bed5..904881493b32 100644
--- a/drivers/clk/samsung/clk-exynos5420.c
+++ b/drivers/clk/samsung/clk-exynos5420.c
@@ -770,7 +770,7 @@ static struct samsung_pll_clock exynos5420_plls[nr_plls]
__initdata = {
KPLL_CON0, NULL),
};
-static struct of_device_id ext_clk_match[] __initdata = {
+static const struct of_device_id ext_clk_match[] __initconst = {
{ .compatible = "samsung,exynos5420-oscclk", .data = (void *)0, },
{ },
};
diff --git a/drivers/clk/samsung/clk-exynos5440.c
b/drivers/clk/samsung/clk-exynos5440.c
index 2bfad5a993d0..ff70bfed5ef8 100644
--- a/drivers/clk/samsung/clk-exynos5440.c
+++ b/drivers/clk/samsung/clk-exynos5440.c
@@ -84,7 +84,7 @@ static struct samsung_gate_clock exynos5440_gate_clks[]
__initdata = {
GATE(CLK_CS250_O, "cs250_o", "cs250", CLKEN_OV_VAL, 19, 0, 0),
};
-static struct of_device_id ext_clk_match[] __initdata = {
+static const struct of_device_id ext_clk_match[] __initconst = {
{ .compatible = "samsung,clock-xtal", .data = (void *)0, },
{},
};
diff --git a/drivers/clk/samsung/clk.c b/drivers/clk/samsung/clk.c
index 91bec3ebdc8f..f9914a8b02ae 100644
--- a/drivers/clk/samsung/clk.c
+++ b/drivers/clk/samsung/clk.c
@@ -269,7 +269,7 @@ void __init samsung_clk_register_gate(struct
samsung_gate_clock *list,
void __init samsung_clk_of_register_fixed_ext(
struct samsung_fixed_rate_clock *fixed_rate_clk,
unsigned int nr_fixed_rate_clk,
- struct of_device_id *clk_matches)
+ const struct of_device_id *clk_matches)
{
const struct of_device_id *match;
struct device_node *np;
diff --git a/drivers/clk/samsung/clk.h b/drivers/clk/samsung/clk.h
index c7141ba826e0..dc8f2cc6f486 100644
--- a/drivers/clk/samsung/clk.h
+++ b/drivers/clk/samsung/clk.h
@@ -317,7 +317,7 @@ extern void __init samsung_clk_init(struct device_node *np,
void __iomem *base,
extern void __init samsung_clk_of_register_fixed_ext(
struct samsung_fixed_rate_clock *fixed_rate_clk,
unsigned int nr_fixed_rate_clk,
- struct of_device_id *clk_matches);
+ const struct of_device_id *clk_matches);
extern void samsung_clk_add_lookup(struct clk *clk, unsigned int id);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 07/14] mmc: mmci: add ddrmode mask to variant data
On Thu, May 15, 2014 at 11:37 AM, wrote: > From: Srinivas Kandagatla > > This patch adds ddrmode mask to variant structure giving more flexibility > to the driver to support more SOCs which have different datactrl register > layout. > > Without this patch datactrl register is updated with wrong ddrmode mask on non > ST SOCs, resulting in card detection failures. > > Signed-off-by: Srinivas Kandagatla Reviewed-by: Linus Walleij Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 08/14] mmc: mmci: add 8bit bus support in variant data
On Thu, May 15, 2014 at 11:37 AM, wrote: > From: Srinivas Kandagatla > > This patch adds 8bit bus enable to variant structure giving more flexibility > to the driver to support more SOCs which have different clock register layout. > > Without this patch other new SOCs like Qcom will have to add more code > to special case them. > > Signed-off-by: Srinivas Kandagatla Reviewed-by: Linus Walleij Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 00/49] DaVinci: vpif: upgrade with v4l helpers and v4l compliance fixes
On 05/16/2014 03:33 PM, Lad, Prabhakar wrote: > From: "Lad, Prabhakar" > > Hi, > > This patch series upgrades the vpif capture & display > driver with the all the helpers provided by v4l, this makes > the driver much simpler and cleaner. This also includes few > checkpatch issues. > > Changes for v2: > a> Added a copyright. > b> Dropped buf_init() callback from vb2_ops. > c> Fixed enabling & disabling of interrupts in case of HD formats. > > Changes for v3: > a> Fixed review comments pointed by Hans. > > Changes for v4: Rebased the patches on media tree. > > Changes for v5: Split up the patches > > Following is the output of v4l-compliance for capture: > -- > > ./v4l2-compliance -d /dev/video0 -i 0 -s -v --expbuf-device=2 > > Driver Info: > Driver name : vpif_capture > Card type : DA850/OMAP-L138 Video Capture > Bus info : platform:vpif_capture > Driver version: 3.15.0 > Capabilities : 0x8401 > Video Capture > Streaming > Device Capabilities > Device Caps : 0x0401 > Video Capture > Streaming > > Compliance test for device /dev/video0 (not using libv4l2): > > Required ioctls: > test VIDIOC_QUERYCAP: OK > > Allow for multiple opens: > test second video open: OK > test VIDIOC_QUERYCAP: OK > test VIDIOC_G/S_PRIORITY: OK > > Debug ioctls: > test VIDIOC_DBG_G/S_REGISTER: OK (Not Supported) > test VIDIOC_LOG_STATUS: OK > > Input ioctls: > test VIDIOC_G/S_TUNER: OK (Not Supported) > test VIDIOC_G/S_FREQUENCY: OK (Not Supported) > test VIDIOC_S_HW_FREQ_SEEK: OK (Not Supported) > test VIDIOC_ENUMAUDIO: OK (Not Supported) > test VIDIOC_G/S/ENUMINPUT: OK > test VIDIOC_G/S_AUDIO: OK (Not Supported) > Inputs: 1 Audio Inputs: 0 Tuners: 0 > > Output ioctls: > test VIDIOC_G/S_MODULATOR: OK (Not Supported) > test VIDIOC_G/S_FREQUENCY: OK (Not Supported) > test VIDIOC_ENUMAUDOUT: OK (Not Supported) > test VIDIOC_G/S/ENUMOUTPUT: OK (Not Supported) > test VIDIOC_G/S_AUDOUT: OK (Not Supported) > Outputs: 0 Audio Outputs: 0 Modulators: 0 > > Input/Output configuration ioctls: > test VIDIOC_ENUM/G/S/QUERY_STD: OK > test VIDIOC_ENUM/G/S/QUERY_DV_TIMINGS: OK (Not Supported) > test VIDIOC_DV_TIMINGS_CAP: OK (Not Supported) > test VIDIOC_G/S_EDID: OK (Not Supported) > > Test input 0: > > Control ioctls: > test VIDIOC_QUERYCTRL/MENU: OK (Not Supported) > test VIDIOC_G/S_CTRL: OK (Not Supported) > test VIDIOC_G/S/TRY_EXT_CTRLS: OK (Not Supported) > test VIDIOC_(UN)SUBSCRIBE_EVENT/DQEVENT: OK (Not Supported) > test VIDIOC_G/S_JPEGCOMP: OK (Not Supported) > Standard Controls: 0 Private Controls: 0 > > Format ioctls: > info: found 1 formats for buftype 1 > test VIDIOC_ENUM_FMT/FRAMESIZES/FRAMEINTERVALS: OK > fail: v4l2-test-formats.cpp(1003): cap->readbuffers Just set readbuffers to 3, which is what queue_setup uses as well as the minimum number of buffers. > test VIDIOC_G/S_PARM: FAIL > test VIDIOC_G_FBUF: OK (Not Supported) > test VIDIOC_G_FMT: OK > test VIDIOC_TRY_FMT: OK > test VIDIOC_S_FMT: OK > test VIDIOC_G_SLICED_VBI_CAP: OK (Not Supported) > > Codec ioctls: > test VIDIOC_(TRY_)ENCODER_CMD: OK (Not Supported) > test VIDIOC_G_ENC_INDEX: OK (Not Supported) > test VIDIOC_(TRY_)DECODER_CMD: OK (Not Supported) > > Buffer ioctls: > info: test buftype Video Capture > test VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF: OK > test VIDIOC_EXPBUF: OK > test read/write: OK (Not Supported) > Video Capture: > Buffer: 0 Sequence: 0 Field: Interlaced Timestamp: 145.509130s This is strange: the sequence number is not updated for each field, but why doesn't v4l2-compliance fail on that? If I hack vivi to always return sequence 0 the compliance tool immediately fails on that. Can you find out why v4l2-compliance doesn't fail here? The check happens in v4l2-test-buffers.cpp, line 321. > Buffer: 1 Sequence: 0 Field: Interlaced Timestamp: 145.549125s > Buffer: 2 Sequence: 0 Field: Interlaced Timestamp: 145.589148s > Buffer: 3 Sequence: 0 Field: Interlaced Timestamp: 145.629106s > Buffer: 0 Sequence: 0 Field: Interlaced Timestamp: 145.669110s > Buffer: 1 Sequence: 0 Field: Interlaced Timestamp: 145.709102s > Buffer: 2 Sequence: 0 Field: Interlaced Timestamp: 145.749099s > Buf
linux-next: manual merge of the target-updates tree with the tree
Hi Nicholas,
Today's linux-next merge of the target-updates tree got a conflict in
drivers/scsi/virtio_scsi.c between commit b54197c43db8 ("virtio_scsi:
use cmd_size") from the scsi tree and commit 4baaa7d589e2
("virtio-scsi: Enable DIF/DIX modes in SCSI host LLD") from the
target-updates tree.
I fixed it up (I think - see below) and can carry the fix as necessary
(no action is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/scsi/virtio_scsi.c
index d4727b339474,cc634b0e8f04..
--- a/drivers/scsi/virtio_scsi.c
+++ b/drivers/scsi/virtio_scsi.c
@@@ -456,9 -537,10 +497,10 @@@ static int virtscsi_queuecommand(struc
struct virtio_scsi_vq *req_vq,
struct scsi_cmnd *sc)
{
- struct virtio_scsi_cmd *cmd;
- int ret, req_size;
-
++ int req_size;
struct Scsi_Host *shost = virtio_scsi_host(vscsi->vdev);
+ struct virtio_scsi_cmd *cmd = scsi_cmd_priv(sc);
+
BUG_ON(scsi_sg_count(sc) > shost->sg_tablesize);
/* TODO: check feature bit and fail if unsupported? */
@@@ -467,27 -549,34 +509,25 @@@
dev_dbg(&sc->device->sdev_gendev,
"cmd %p CDB: %#02x\n", sc, sc->cmnd[0]);
- ret = SCSI_MLQUEUE_HOST_BUSY;
- cmd = mempool_alloc(virtscsi_cmd_pool, GFP_ATOMIC);
- if (!cmd)
- goto out;
-
memset(cmd, 0, sizeof(*cmd));
cmd->sc = sc;
- cmd->req.cmd = (struct virtio_scsi_cmd_req){
- .lun[0] = 1,
- .lun[1] = sc->device->id,
- .lun[2] = (sc->device->lun >> 8) | 0x40,
- .lun[3] = sc->device->lun & 0xff,
- .tag = (unsigned long)sc,
- .task_attr = VIRTIO_SCSI_S_SIMPLE,
- .prio = 0,
- .crn = 0,
- };
BUG_ON(sc->cmd_len > VIRTIO_SCSI_CDB_SIZE);
- memcpy(cmd->req.cmd.cdb, sc->cmnd, sc->cmd_len);
- if (virtscsi_kick_cmd(req_vq, cmd,
- sizeof cmd->req.cmd, sizeof cmd->resp.cmd,
+ if (virtio_has_feature(vscsi->vdev, VIRTIO_SCSI_F_T10_PI)) {
+ virtio_scsi_init_hdr_pi(&cmd->req.cmd_pi, sc);
+ memcpy(cmd->req.cmd_pi.cdb, sc->cmnd, sc->cmd_len);
+ req_size = sizeof(cmd->req.cmd_pi);
+ } else {
+ virtio_scsi_init_hdr(&cmd->req.cmd, sc);
+ memcpy(cmd->req.cmd.cdb, sc->cmnd, sc->cmd_len);
+ req_size = sizeof(cmd->req.cmd);
+ }
+
+ if (virtscsi_kick_cmd(req_vq, cmd, req_size, sizeof(cmd->resp.cmd),
-GFP_ATOMIC) == 0)
- ret = 0;
- else
- mempool_free(cmd, virtscsi_cmd_pool);
-
-out:
- return ret;
+GFP_ATOMIC) != 0)
+ return SCSI_MLQUEUE_HOST_BUSY;
+ return 0;
}
static int virtscsi_queuecommand_single(struct Scsi_Host *sh,
signature.asc
Description: PGP signature
Re: [PATCH v2 09/14] mmc: mmci: add edge support to data and command out in variant data.
On Thu, May 15, 2014 at 11:37 AM, wrote: > From: Srinivas Kandagatla > > This patch adds edge support for data and command out to variant structure > giving more flexibility to the driver to support more SOCs which have > different clock register layout. > > Without this patch other new SOCs like Qcom will have to add more code to > special case them > > Signed-off-by: Srinivas Kandagatla Reviewed-by: Linus Walleij Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 10/14] mmc: mmci: add Qcom specifics of clk and datactrl registers.
On Thu, May 15, 2014 at 11:37 AM, wrote: > From: Srinivas Kandagatla > > This patch adds specifics of clk and datactrl register on Qualcomm SD > Card controller. This patch also populates the Qcom variant data with > these new values specific to Qualcomm SD Card Controller. > > Signed-off-by: Srinivas Kandagatla Now it looks real elegant. Reviewed-by: Linus Walleij Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [RESEND] ARM: remove last use of CONFIG_CPU_ARM710
On Wed, 2014-05-14 at 11:28 +0200, Arnd Bergmann wrote: > On Wednesday 14 May 2014 11:25:50 Paul Bolle wrote: > > On Wed, 2014-05-14 at 11:17 +0200, Arnd Bergmann wrote: > > > 'git grep -i arm710' tells me that there is also some arm710 > > > specific code in arch/arm/mm/proc-arm720.S that we may want to > > > remove along with this. > > > > > > The DT binding should probably remain untouched though, I think it's > > > correct to document the string. > > > > That seems to be cpu_arm710_name, __arm710_setup, and everything called > > by __arm710_setup. Cleaning that up (as a separate patch) appears to be > > trivial. If I do that it would be (sort of educated) guesswork. But I > > don't mind doing it. What do you prefer? > > I think that would be great. For the first patch, please add > > Acked-by: Arnd Bergmann > > Once the second patch is reviewed, please add them both to Russell's > patch tracker. Well, at least that second patch triggered a nice conversation. So I should now add the first patch (with your ACK) to the tracker? Paul Bolle -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 0/5] Add platform support for LSI AXM55xx
Hi, Here is version 4 of platform support for AXM5516 SoC. The clk driver is now applied to clk-next. The rest should be ready for arm-soc. Haven't got any response from the power/reset maintainers... I hope this driver can be taken via arm-soc as well. Changes: v4: * Updated DTS according to new clk driver binding. * Dropped the clk driver from this series. v3: * Sorted Kconfig entries alphabetically v2: * Rebased to arm-soc/for-next * Removed redundant HAVE_SMP and ARCH_WANT_OPTIONAL_GPIOLIB from Kconfig * Use CPU_METHOD_OF_DECLARE to register smp_operations * Rework smp operations to avoid holding pen and custom headsmp.S * Clean up board file * Corrected clock properties for arm,sp804 dts node. * Changed machine compatible strings to include full model number. * Break out clk-axxia driver as separate patch * Removed Makefile.boot Anders Berg (5): ARM: Add platform support for LSI AXM55xx SoC ARM: dts: Device tree for AXM55xx. ARM: axxia: Adding defconfig for AXM55xx power: reset: Add Axxia system reset driver ARM: dts: axxia: Add reset controller Documentation/devicetree/bindings/arm/axxia.txt| 12 + .../bindings/power_supply/axxia-reset.txt | 20 ++ arch/arm/Kconfig | 2 + arch/arm/Makefile | 2 + arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/axm5516-amarillo.dts | 51 + arch/arm/boot/dts/axm5516-cpus.dtsi| 204 + arch/arm/boot/dts/axm55xx.dtsi | 204 + arch/arm/configs/axm55xx_defconfig | 248 + arch/arm/mach-axxia/Kconfig| 16 ++ arch/arm/mach-axxia/Makefile | 2 + arch/arm/mach-axxia/axxia.c| 28 +++ arch/arm/mach-axxia/platsmp.c | 89 drivers/power/reset/Kconfig| 8 + drivers/power/reset/Makefile | 1 + drivers/power/reset/axxia-reset.c | 88 include/dt-bindings/clock/lsi,axm5516-clks.h | 36 +++ 17 files changed, 1012 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/axxia.txt create mode 100644 Documentation/devicetree/bindings/power_supply/axxia-reset.txt create mode 100644 arch/arm/boot/dts/axm5516-amarillo.dts create mode 100644 arch/arm/boot/dts/axm5516-cpus.dtsi create mode 100644 arch/arm/boot/dts/axm55xx.dtsi create mode 100644 arch/arm/configs/axm55xx_defconfig create mode 100644 arch/arm/mach-axxia/Kconfig create mode 100644 arch/arm/mach-axxia/Makefile create mode 100644 arch/arm/mach-axxia/axxia.c create mode 100644 arch/arm/mach-axxia/platsmp.c create mode 100644 drivers/power/reset/axxia-reset.c create mode 100644 include/dt-bindings/clock/lsi,axm5516-clks.h -- 1.8.3.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 4/5] power: reset: Add Axxia system reset driver
From: Anders Berg
Add Axxia (AXM55xx) SoC system reset driver. This driver handles only system
reboot (and not power-off).
Signed-off-by: Anders Berg
Cc: Dmitry Eremin-Solenikov
Cc: David Woodhouse
Acked-by: Linus Walleij
---
.../bindings/power_supply/axxia-reset.txt | 20 +
drivers/power/reset/Kconfig| 8 ++
drivers/power/reset/Makefile | 1 +
drivers/power/reset/axxia-reset.c | 88 ++
4 files changed, 117 insertions(+)
create mode 100644
Documentation/devicetree/bindings/power_supply/axxia-reset.txt
create mode 100644 drivers/power/reset/axxia-reset.c
diff --git a/Documentation/devicetree/bindings/power_supply/axxia-reset.txt
b/Documentation/devicetree/bindings/power_supply/axxia-reset.txt
new file mode 100644
index 000..47e720d
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/axxia-reset.txt
@@ -0,0 +1,20 @@
+Axxia Restart Driver
+
+This driver can do reset of the Axxia SoC. It uses the registers in the syscon
+block to initiate a chip reset.
+
+Required Properties:
+ -compatible: "lsi,axm55xx-reset"
+ -syscon: phandle to the syscon node.
+
+Example:
+
+ syscon: syscon@201003 {
+ compatible = "lsi,axxia-syscon", "syscon";
+ reg = <0x20 0x1003 0 0x2000>;
+ };
+
+ reset: reset@2010031000 {
+ compatible = "lsi,axm55xx-reset";
+ syscon = <&syscon>;
+ };
diff --git a/drivers/power/reset/Kconfig b/drivers/power/reset/Kconfig
index fa0e4e0..49b46e6 100644
--- a/drivers/power/reset/Kconfig
+++ b/drivers/power/reset/Kconfig
@@ -12,6 +12,14 @@ config POWER_RESET_AS3722
help
This driver supports turning off board via a ams AS3722 power-off.
+config POWER_RESET_AXXIA
+ bool "LSI Axxia reset driver"
+ depends on POWER_RESET && ARCH_AXXIA
+ help
+ This driver supports restart for Axxia SoC.
+
+ Say Y if you have an Axxia family SoC.
+
config POWER_RESET_GPIO
bool "GPIO power-off driver"
depends on OF_GPIO && POWER_RESET
diff --git a/drivers/power/reset/Makefile b/drivers/power/reset/Makefile
index a5b4a77..16c0516 100644
--- a/drivers/power/reset/Makefile
+++ b/drivers/power/reset/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_POWER_RESET_AS3722) += as3722-poweroff.o
+obj-$(CONFIG_POWER_RESET_AXXIA) += axxia-reset.o
obj-$(CONFIG_POWER_RESET_GPIO) += gpio-poweroff.o
obj-$(CONFIG_POWER_RESET_MSM) += msm-poweroff.o
obj-$(CONFIG_POWER_RESET_QNAP) += qnap-poweroff.o
diff --git a/drivers/power/reset/axxia-reset.c
b/drivers/power/reset/axxia-reset.c
new file mode 100644
index 000..3b1f8d6
--- /dev/null
+++ b/drivers/power/reset/axxia-reset.c
@@ -0,0 +1,88 @@
+/*
+ * Reset driver for Axxia devices
+ *
+ * Copyright (C) 2014 LSI
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+
+#define SC_CRIT_WRITE_KEY 0x1000
+#define SC_LATCH_ON_RESET 0x1004
+#define SC_RESET_CONTROL 0x1008
+#define RSTCTL_RST_ZERO (1<<3)
+#define RSTCTL_RST_FAB (1<<2)
+#define RSTCTL_RST_CHIP (1<<1)
+#define RSTCTL_RST_SYS (1<<0)
+#define SC_EFUSE_INT_STATUS0x180c
+#define EFUSE_READ_DONE (1<<31)
+
+static struct regmap *syscon;
+
+static void do_axxia_restart(enum reboot_mode reboot_mode, const char *cmd)
+{
+ /* Access Key (0xab) */
+ regmap_write(syscon, SC_CRIT_WRITE_KEY, 0xab);
+ /* Select internal boot from 0x */
+ regmap_write(syscon, SC_LATCH_ON_RESET, 0x0040);
+ /* Assert ResetReadDone (to avoid hanging in boot ROM) */
+ regmap_write(syscon, SC_EFUSE_INT_STATUS, EFUSE_READ_DONE);
+ /* Assert chip reset */
+ regmap_update_bits(syscon, SC_RESET_CONTROL,
+ RSTCTL_RST_CHIP, RSTCTL_RST_CHIP);
+}
+
+static int axxia_reset_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+
+ syscon = syscon_regmap_lookup_by_phandle(dev->of_node, "syscon");
+ if (IS_ERR(syscon)) {
+ pr_err("%s: syscon lookup failed\n", dev->of_node->name);
+ return PTR_ERR(syscon);
+ }
+
+ arm_pm_restart = do_axxia_restart;
+
+ return 0;
+}
+
+static const struct of_device_id of_axxia_reset_match[] = {
+ { .compatible = "lsi,axm55xx-reset", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, of_axxia_reset_match);
+
+static struct p
Re: [PATCH v2 11/14] mmc: mmci: Add support to data commands via variant structure.
On Thu, May 15, 2014 at 11:37 AM, wrote: > From: Srinivas Kandagatla > > On some SOCs like Qcom there are explicit bits in the command register > to specify if its a data transfer command or not. So this patch adds > support to such bits in variant data, giving more flexibility to the > driver. > > Signed-off-by: Srinivas Kandagatla Reviewed-by: Linus Walleij Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 11/14] mmc: mmci: Add support to data commands via variant structure.
Thanks Linus W. On 23/05/14 10:09, Linus Walleij wrote: On Thu, May 15, 2014 at 11:37 AM, wrote: From: Srinivas Kandagatla On some SOCs like Qcom there are explicit bits in the command register to specify if its a data transfer command or not. So this patch adds support to such bits in variant data, giving more flexibility to the driver. Signed-off-by: Srinivas Kandagatla Reviewed-by: Linus Walleij Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] x86/mce: Distirbute the clear operation of mces_seen to Per-CPU rather than only monarch CPU
On Fri, May 23, 2014 at 09:32:19AM +0800, Chen Yucong wrote:
> ...if we reach a timeout, there is very little
> chance for recovering. Thought. the probability for this situation to
> happen is very slight, it's not impossible. Indeed, it's hard to know
> the precise causes for timeout.
Ok, enough talking, let's close that hole and get on with our lives:
---
From: Borislav Petkov
Date: Fri, 23 May 2014 11:06:35 +0200
Subject: [PATCH] mce: Panic when a core has reached a timeout
There is very little and maybe practically nothing we can do to recover
from a system where at least one core has reached a timeout during the
whole monarch cores gathering. So panic when that happens.
Signed-off-by: Borislav Petkov
---
arch/x86/kernel/cpu/mcheck/mce.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index bfde4871848f..529ccc488f5a 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -704,8 +704,7 @@ static int mce_timed_out(u64 *t)
if (!mca_cfg.monarch_timeout)
goto out;
if ((s64)*t < SPINUNIT) {
- /* CHECKME: Make panic default for 1 too? */
- if (mca_cfg.tolerant < 1)
+ if (mca_cfg.tolerant <= 1)
mce_panic("Timeout synchronizing machine check over
CPUs",
NULL, NULL);
cpu_missing = 1;
--
1.9.0
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 3/5] ARM: axxia: Adding defconfig for AXM55xx
From: Anders Berg Add a defconfig file for the LSI Axxia family of devices (CONFIG_ARCH_AXXIA). Signed-off-by: Anders Berg Acked-by: Linus Walleij --- arch/arm/configs/axm55xx_defconfig | 248 + 1 file changed, 248 insertions(+) create mode 100644 arch/arm/configs/axm55xx_defconfig diff --git a/arch/arm/configs/axm55xx_defconfig b/arch/arm/configs/axm55xx_defconfig new file mode 100644 index 000..d3260d7 --- /dev/null +++ b/arch/arm/configs/axm55xx_defconfig @@ -0,0 +1,248 @@ +CONFIG_SYSVIPC=y +CONFIG_POSIX_MQUEUE=y +CONFIG_FHANDLE=y +CONFIG_AUDIT=y +CONFIG_HIGH_RES_TIMERS=y +CONFIG_BSD_PROCESS_ACCT=y +CONFIG_BSD_PROCESS_ACCT_V3=y +CONFIG_TASKSTATS=y +CONFIG_TASK_DELAY_ACCT=y +CONFIG_TASK_XACCT=y +CONFIG_TASK_IO_ACCOUNTING=y +CONFIG_IKCONFIG=y +CONFIG_IKCONFIG_PROC=y +CONFIG_LOG_BUF_SHIFT=16 +CONFIG_NAMESPACES=y +# CONFIG_UTS_NS is not set +# CONFIG_IPC_NS is not set +# CONFIG_PID_NS is not set +# CONFIG_NET_NS is not set +CONFIG_SCHED_AUTOGROUP=y +CONFIG_RELAY=y +CONFIG_BLK_DEV_INITRD=y +CONFIG_SYSCTL_SYSCALL=y +CONFIG_EMBEDDED=y +# CONFIG_COMPAT_BRK is not set +CONFIG_PROFILING=y +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +# CONFIG_IOSCHED_DEADLINE is not set +CONFIG_ARCH_AXXIA=y +CONFIG_GPIO_PCA953X=y +CONFIG_ARM_LPAE=y +CONFIG_ARM_THUMBEE=y +CONFIG_ARM_ERRATA_430973=y +CONFIG_ARM_ERRATA_643719=y +CONFIG_ARM_ERRATA_720789=y +CONFIG_ARM_ERRATA_754322=y +CONFIG_ARM_ERRATA_754327=y +CONFIG_ARM_ERRATA_764369=y +CONFIG_ARM_ERRATA_775420=y +CONFIG_ARM_ERRATA_798181=y +CONFIG_PCI=y +CONFIG_PCI_MSI=y +CONFIG_PCIE_AXXIA=y +CONFIG_SMP=y +CONFIG_NR_CPUS=16 +CONFIG_HOTPLUG_CPU=y +CONFIG_PREEMPT=y +CONFIG_AEABI=y +CONFIG_OABI_COMPAT=y +CONFIG_HIGHMEM=y +CONFIG_KSM=y +CONFIG_ZBOOT_ROM_TEXT=0x0 +CONFIG_ZBOOT_ROM_BSS=0x0 +CONFIG_ARM_APPENDED_DTB=y +CONFIG_ARM_ATAG_DTB_COMPAT=y +CONFIG_VFP=y +CONFIG_NEON=y +# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set +CONFIG_BINFMT_MISC=y +# CONFIG_SUSPEND is not set +CONFIG_NET=y +CONFIG_PACKET=y +CONFIG_UNIX=y +CONFIG_XFRM_USER=y +CONFIG_XFRM_SUB_POLICY=y +CONFIG_XFRM_MIGRATE=y +CONFIG_XFRM_STATISTICS=y +CONFIG_NET_KEY=y +CONFIG_INET=y +CONFIG_IP_PNP=y +CONFIG_IP_PNP_DHCP=y +CONFIG_IP_PNP_BOOTP=y +CONFIG_INET_AH=y +CONFIG_INET_ESP=y +CONFIG_INET_IPCOMP=y +# CONFIG_INET_LRO is not set +# CONFIG_IPV6 is not set +CONFIG_NETWORK_PHY_TIMESTAMPING=y +CONFIG_BRIDGE=y +# CONFIG_WIRELESS is not set +CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" +CONFIG_DEVTMPFS=y +CONFIG_DEVTMPFS_MOUNT=y +CONFIG_MTD=y +CONFIG_MTD_CMDLINE_PARTS=y +CONFIG_MTD_AFS_PARTS=y +CONFIG_MTD_BLOCK=y +CONFIG_MTD_CFI=y +CONFIG_MTD_CFI_INTELEXT=y +CONFIG_MTD_CFI_AMDSTD=y +CONFIG_MTD_CFI_STAA=y +CONFIG_MTD_PHYSMAP=y +CONFIG_MTD_PHYSMAP_OF=y +CONFIG_MTD_M25P80=y +CONFIG_PROC_DEVICETREE=y +CONFIG_BLK_DEV_LOOP=y +CONFIG_BLK_DEV_RAM=y +CONFIG_EEPROM_AT24=y +CONFIG_EEPROM_AT25=y +CONFIG_BLK_DEV_SD=y +CONFIG_CHR_DEV_SG=y +CONFIG_ATA=y +CONFIG_PATA_PLATFORM=y +CONFIG_PATA_OF_PLATFORM=y +CONFIG_MD=y +CONFIG_BLK_DEV_DM=y +CONFIG_DM_UEVENT=y +CONFIG_NETDEVICES=y +CONFIG_TUN=y +CONFIG_VETH=y +CONFIG_VIRTIO_NET=y +# CONFIG_NET_CADENCE is not set +# CONFIG_NET_VENDOR_BROADCOM is not set +# CONFIG_NET_VENDOR_CIRRUS is not set +# CONFIG_NET_VENDOR_FARADAY is not set +# CONFIG_NET_VENDOR_INTEL is not set +# CONFIG_NET_VENDOR_MARVELL is not set +# CONFIG_NET_VENDOR_MICREL is not set +# CONFIG_NET_VENDOR_NATSEMI is not set +# CONFIG_NET_VENDOR_SEEQ is not set +# CONFIG_NET_VENDOR_SMSC is not set +# CONFIG_NET_VENDOR_STMICRO is not set +# CONFIG_NET_VENDOR_VIA is not set +# CONFIG_NET_VENDOR_WIZNET is not set +CONFIG_BROADCOM_PHY=y +# CONFIG_WLAN is not set +# CONFIG_MOUSE_PS2_ALPS is not set +# CONFIG_MOUSE_PS2_LOGIPS2PP is not set +# CONFIG_MOUSE_PS2_SYNAPTICS is not set +# CONFIG_MOUSE_PS2_TRACKPOINT is not set +# CONFIG_SERIO_SERPORT is not set +CONFIG_SERIO_AMBAKMI=y +CONFIG_LEGACY_PTY_COUNT=16 +CONFIG_SERIAL_AMBA_PL011=y +CONFIG_SERIAL_AMBA_PL011_CONSOLE=y +CONFIG_VIRTIO_CONSOLE=y +# CONFIG_HW_RANDOM is not set +CONFIG_I2C=y +CONFIG_I2C_CHARDEV=y +CONFIG_I2C_MUX=y +CONFIG_I2C_AXXIA=y +CONFIG_SPI=y +CONFIG_SPI_PL022=y +CONFIG_DP83640_PHY=y +CONFIG_GPIOLIB=y +CONFIG_GPIO_SYSFS=y +CONFIG_GPIO_PL061=y +CONFIG_POWER_SUPPLY=y +CONFIG_POWER_RESET=y +CONFIG_POWER_RESET_AXXIA=y +CONFIG_SENSORS_ADT7475=y +CONFIG_SENSORS_JC42=y +CONFIG_SENSORS_LM75=y +CONFIG_PMBUS=y +CONFIG_SENSORS_LTC2978=y +CONFIG_WATCHDOG=y +CONFIG_ARM_SP805_WATCHDOG=y +CONFIG_FB=y +CONFIG_FB_ARMCLCD=y +CONFIG_FRAMEBUFFER_CONSOLE=y +CONFIG_LOGO=y +# CONFIG_LOGO_LINUX_MONO is not set +# CONFIG_LOGO_LINUX_VGA16 is not set +CONFIG_HID_A4TECH=y +CONFIG_HID_APPLE=y +CONFIG_HID_BELKIN=y +CONFIG_HID_CHERRY=y +CONFIG_HID_CHICONY=y +CONFIG_HID_CYPRESS=y +CONFIG_HID_DRAGONRISE=y +CONFIG_HID_EZKEY=y +CONFIG_HID_KYE=y +CONFIG_HID_GYRATION=y +CONFIG_HID_TWINHAN=y +CONFIG_HID_KENSINGTON=y +CONFIG_HID_LOGITECH=y +CONFIG_HID_MICROSOFT=y +CONFIG_HID_MONTEREY=y +CONFIG_HID_NTRIG=y +CONFIG_HID_ORTEK=y +CONFIG_HID_PANTHERLORD=y +CONFIG_HID_PETALYNX=
[PATCH v4 5/5] ARM: dts: axxia: Add reset controller
From: Anders Berg
Add the reset controller to the AXM5xx device tree.
Signed-off-by: Anders Berg
Acked-by: Linus Walleij
---
arch/arm/boot/dts/axm55xx.dtsi | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/boot/dts/axm55xx.dtsi b/arch/arm/boot/dts/axm55xx.dtsi
index 3fbd83c..ea288f0 100644
--- a/arch/arm/boot/dts/axm55xx.dtsi
+++ b/arch/arm/boot/dts/axm55xx.dtsi
@@ -101,6 +101,11 @@
reg = <0x20 0x1003 0 0x2000>;
};
+ reset: reset@2010031000 {
+ compatible = "lsi,axm55xx-reset";
+ syscon = <&syscon>;
+ };
+
amba {
compatible = "arm,amba-bus";
#address-cells = <2>;
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 12/14] mmc: mmci: add support for fbclk to latch data and cmd.
On Thu, May 15, 2014 at 11:37 AM, wrote:
> From: Srinivas Kandagatla
>
> This patch adds support to fbclk that is used to latch data and
> cmd on some controllers like SD Card controller in Qcom SOC.
>
> Signed-off-by: Srinivas Kandagatla
(...)
Isn't this overkill?
@@ -189,6 +192,7 @@ static struct variant_data variant_qcom = {
.clkreg = MCI_CLK_ENABLE,
-.clkreg_enable = MCI_QCOM_CLK_FLOWENA,
+ .clkreg_enable = MCI_QCOM_CLK_FLOWENA |
MCI_QCOM_CLK_FEEDBACK_CLK,
.clkreg_8bit_bus_enable = MCI_QCOM_CLK_WIDEBUS_8,
Isn't this achieveing exactly the same thing without the extra fields?
You unconditionally do it at every enable anyway, don't you?
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 2/5] ARM: dts: Device tree for AXM55xx.
From: Anders Berg
Add device tree for the Amarillo validation board with an AXM5516 SoC.
Signed-off-by: Anders Berg
Acked-by: Linus Walleij
---
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/axm5516-amarillo.dts | 51 +
arch/arm/boot/dts/axm5516-cpus.dtsi| 204 +
arch/arm/boot/dts/axm55xx.dtsi | 199
4 files changed, 455 insertions(+)
create mode 100644 arch/arm/boot/dts/axm5516-amarillo.dts
create mode 100644 arch/arm/boot/dts/axm5516-cpus.dtsi
create mode 100644 arch/arm/boot/dts/axm55xx.dtsi
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index ba4c394..3899d59 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -50,6 +50,7 @@ dtb-$(CONFIG_ARCH_AT91) += sama5d35ek.dtb
dtb-$(CONFIG_ARCH_AT91)+= sama5d36ek.dtb
dtb-$(CONFIG_ARCH_ATLAS6) += atlas6-evb.dtb
+dtb-$(CONFIG_ARCH_AXXIA) += axm5516-amarillo.dtb
dtb-$(CONFIG_ARCH_BCM2835) += bcm2835-rpi-b.dtb
dtb-$(CONFIG_ARCH_BCM_5301X) += bcm4708-netgear-r6250.dtb
dtb-$(CONFIG_ARCH_BCM_MOBILE) += bcm28155-ap.dtb \
diff --git a/arch/arm/boot/dts/axm5516-amarillo.dts
b/arch/arm/boot/dts/axm5516-amarillo.dts
new file mode 100644
index 000..a9d6047
--- /dev/null
+++ b/arch/arm/boot/dts/axm5516-amarillo.dts
@@ -0,0 +1,51 @@
+/*
+ * arch/arm/boot/dts/axm5516-amarillo.dts
+ *
+ * Copyright (C) 2013 LSI
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+/dts-v1/;
+
+/memreserve/ 0x 0x0040;
+
+#include "axm55xx.dtsi"
+#include "axm5516-cpus.dtsi"
+
+/ {
+ model = "Amarillo AXM5516";
+ compatible = "lsi,axm5516-amarillo", "lsi,axm5516";
+
+ memory {
+ device_type = "memory";
+ reg = <0 0x 0x02 0x>;
+ };
+};
+
+&serial0 {
+ status = "okay";
+};
+
+&serial1 {
+ status = "okay";
+};
+
+&serial2 {
+ status = "okay";
+};
+
+&serial3 {
+ status = "okay";
+};
+
+&gpio0 {
+ status = "okay";
+};
+
+&gpio1 {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/axm5516-cpus.dtsi
b/arch/arm/boot/dts/axm5516-cpus.dtsi
new file mode 100644
index 000..b85f360
--- /dev/null
+++ b/arch/arm/boot/dts/axm5516-cpus.dtsi
@@ -0,0 +1,204 @@
+/*
+ * arch/arm/boot/dts/axm5516-cpus.dtsi
+ *
+ * Copyright (C) 2013 LSI
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+/ {
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <&CPU0>;
+ };
+ core1 {
+ cpu = <&CPU1>;
+ };
+ core2 {
+ cpu = <&CPU2>;
+ };
+ core3 {
+ cpu = <&CPU3>;
+ };
+ };
+ cluster1 {
+ core0 {
+ cpu = <&CPU4>;
+ };
+ core1 {
+ cpu = <&CPU5>;
+ };
+ core2 {
+ cpu = <&CPU6>;
+ };
+ core3 {
+ cpu = <&CPU7>;
+ };
+ };
+ cluster2 {
+ core0 {
+ cpu = <&CPU8>;
+ };
+ core1 {
+ cpu = <&CPU9>;
+ };
+ core2 {
+ cpu = <&CPU10>;
+ };
+ core3 {
+ cpu = <&CPU11>;
+ };
+ };
+ cluster3 {
+ core0 {
+ cpu = <&CPU12>;
+ };
+ core1 {
+ cpu = <&CPU13>;
+
