Re: [PATCH] pwm: Fix of_pwm_get() for consistent return values
On Sun, Nov 29, 2015 at 02:17:37PM +0100, Alban Bedel wrote: > When of_pwm_get() is called without connection ID it returns > -ENOENT when the 'pwms' property doesn't exists or is an empty entry. > However when a connection ID is given and the 'pwm-names' property > doesn't exists or doesn't contains the requested name it returns > -ENODATA or -EINVAL. > > To get a consistent return value with both code paths we must return > -ENOENT when of_property_match_string() fails. I'm not sure I understand the need for a consistent return value here. These are all different error conditions and the only reasonable thing to do here is propagate the error code from the of_*() parsing routine that is being called. Thierry signature.asc Description: PGP signature
Re: [PATCH 01/19] irqchip: atmel-aic: fix wrong bit operation for IRQ priority
Hi Milo,
On Mon, 4 Jan 2016 13:28:25 +0900
Milo Kim wrote:
> Atmel AIC has common structure for SMR (Source Mode Register).
>
> bit[6:5] Interrupt source type
> bit[2:0] Priority level
> Other bits are unused.
>
> To update new priority value, bit[2:0] should be cleared first and then
> new priority level can be written. However, aic_common_set_priority()
> helper clears source type bits instead of priority bits.
> This patch fixes wrong mask bit operation.
>
> Cc: Thomas Gleixner
> Cc: Jason Cooper
> Cc: Marc Zyngier
> Cc: Alexandre Belloni
> Cc: Boris BREZILLON
> Cc: Ludovic Desroches
> Cc: Nicolas Ferre
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Milo Kim
Acked-by: Boris Brezillon
Can you also add
Fixes: b1479ebb7720 ("irqchip: atmel-aic: Add atmel AIC/AIC5 drivers")
Cc: sta...@vger.kernel.org #v3.17+
Thanks,
Boris
> ---
> drivers/irqchip/irq-atmel-aic-common.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/irqchip/irq-atmel-aic-common.c
> b/drivers/irqchip/irq-atmel-aic-common.c
> index b12a5d5..37199b9 100644
> --- a/drivers/irqchip/irq-atmel-aic-common.c
> +++ b/drivers/irqchip/irq-atmel-aic-common.c
> @@ -86,7 +86,7 @@ int aic_common_set_priority(int priority, unsigned *val)
> priority > AT91_AIC_IRQ_MAX_PRIORITY)
> return -EINVAL;
>
> - *val &= AT91_AIC_PRIOR;
> + *val &= ~AT91_AIC_PRIOR;
> *val |= priority;
>
> return 0;
--
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/
[PATCH v2] ehci-hcd: Cleanup memory resources when ehci_halt fails
The driver calls ehci_mem_init to allocate memory resources.
But these resources are not freed when ehci_halt fails.
This patch adds "ehci_mem_cleanup" in error handling code to fix this problem.
Signed-off-by: Jia-Ju Bai
---
drivers/usb/host/ehci-hcd.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 48c92bf..015b411 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -675,8 +675,10 @@ int ehci_setup(struct usb_hcd *hcd)
return retval;
retval = ehci_halt(ehci);
- if (retval)
+ if (retval) {
+ ehci_mem_cleanup(ehci);
return retval;
+ }
ehci_reset(ehci);
--
1.7.9.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/
[PATCH v2] ehci-hcd: Disable memory-write-invalidate when the driver is removed
The driver calls pci_set_mwi to enable memory-write-invalidate when it
is initialized, but does not call pci_clear_mwi when it is removed. Many
other drivers calls pci_clear_mwi when pci_set_mwi is called, such as
r8169, 8139cp and e1000.
This patch adds a function "ehci_pci_remove" to remove the pci driver.
This function calls pci_clear_mwi and usb_hcd_pci_remove, which can
fix the problem.
Signed-off-by: Jia-Ju Bai
---
drivers/usb/host/ehci-pci.c |8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
index 2a5d2fd..3b3649d 100644
--- a/drivers/usb/host/ehci-pci.c
+++ b/drivers/usb/host/ehci-pci.c
@@ -377,6 +377,12 @@ static int ehci_pci_probe(struct pci_dev *pdev, const
struct pci_device_id *id)
return usb_hcd_pci_probe(pdev, id);
}
+static void ehci_pci_remove(struct pci_dev *pdev)
+{
+ pci_clear_mwi(pdev);
+ usb_hcd_pci_remove(pdev);
+}
+
/* PCI driver selection metadata; PCI hotplugging uses this */
static const struct pci_device_id pci_ids [] = { {
/* handle any USB 2.0 EHCI controller */
@@ -396,7 +402,7 @@ static struct pci_driver ehci_pci_driver = {
.id_table = pci_ids,
.probe =ehci_pci_probe,
- .remove = usb_hcd_pci_remove,
+ .remove = ehci_pci_remove,
.shutdown = usb_hcd_pci_shutdown,
#ifdef CONFIG_PM
--
1.7.9.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 02/19] irqchip: atmel-aic: clean up RTC interrupt code
Hi Milo,
On Mon, 4 Jan 2016 13:28:26 +0900
Milo Kim wrote:
> Atmel AIC disables RTC interrupt on initialization. However, the controller
> doesn't need to do it. There are two reasons.
>
> * RTC driver disables interrupts on _probe()
> RTC_IDR is set to 0x1f which means all RTC interrupts are disabled.
> (drivers/rtc/rtc-at91rm9200.c)
> at91_rtc_write_idr(AT91_RTC_ACKUPD | AT91_RTC_ALARM |
> AT91_RTC_SECEV | AT91_RTC_TIMEV |
> AT91_RTC_CALEV);
>
> * All RTC interrupts are disabled by default.
> If we try to read RTC_IMR(interrup mask status), then read value is 0
> by default. It means all RTC interrupts are disabled by default.
> We can also check the default status in the datasheet. Please note that
> all devices have same RTC registers.
> AT91RM9200
> AT91SAM9N12
> AT91SAM9X5
> AT91SAM9G45
> AT91SAM9RL
> SAMA5D3
> SAMA5D4
>
> So, aic_common_rtc_irq_fixup() helper can be removed.
Please read b2f579b58e93 ("irqchip: atmel-aic: Add irq fixup
infrastructure") and 3d61467f9bab ("irqchip: atmel-aic: Implement RTC
irq fixup") messages before assuming you can simply remove these
functions.
There's a good reason behind this irq fixup infrastructure, and you're
blindly removing those functions without asking why we were doing that.
Best Regards,
Boris
>
> Cc: Thomas Gleixner
> Cc: Jason Cooper
> Cc: Marc Zyngier
> Cc: Alexandre Belloni
> Cc: Boris BREZILLON
> Cc: Ludovic Desroches
> Cc: Nicolas Ferre
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Milo Kim
> ---
> drivers/irqchip/irq-atmel-aic-common.c | 28
> drivers/irqchip/irq-atmel-aic-common.h | 2 --
> drivers/irqchip/irq-atmel-aic.c| 9 -
> drivers/irqchip/irq-atmel-aic5.c | 13 -
> 4 files changed, 52 deletions(-)
>
> diff --git a/drivers/irqchip/irq-atmel-aic-common.c
> b/drivers/irqchip/irq-atmel-aic-common.c
> index 37199b9..f8261be 100644
> --- a/drivers/irqchip/irq-atmel-aic-common.c
> +++ b/drivers/irqchip/irq-atmel-aic-common.c
> @@ -139,34 +139,6 @@ static void __init aic_common_ext_irq_of_init(struct
> irq_domain *domain)
> }
> }
>
> -#define AT91_RTC_IDR 0x24
> -#define AT91_RTC_IMR 0x28
> -#define AT91_RTC_IRQ_MASK 0x1f
> -
> -void __init aic_common_rtc_irq_fixup(struct device_node *root)
> -{
> - struct device_node *np;
> - void __iomem *regs;
> -
> - np = of_find_compatible_node(root, NULL, "atmel,at91rm9200-rtc");
> - if (!np)
> - np = of_find_compatible_node(root, NULL,
> - "atmel,at91sam9x5-rtc");
> -
> - if (!np)
> - return;
> -
> - regs = of_iomap(np, 0);
> - of_node_put(np);
> -
> - if (!regs)
> - return;
> -
> - writel(AT91_RTC_IRQ_MASK, regs + AT91_RTC_IDR);
> -
> - iounmap(regs);
> -}
> -
> #define AT91_RTT_MR 0x00/* Real-time Mode
> Register */
> #define AT91_RTT_ALMIEN (1 << 16) /* Alarm
> Interrupt Enable */
> #define AT91_RTT_RTTINCIEN (1 << 17) /* Real Time Timer
> Increment Interrupt Enable */
> diff --git a/drivers/irqchip/irq-atmel-aic-common.h
> b/drivers/irqchip/irq-atmel-aic-common.h
> index 603f0a9..9027f15 100644
> --- a/drivers/irqchip/irq-atmel-aic-common.h
> +++ b/drivers/irqchip/irq-atmel-aic-common.h
> @@ -32,8 +32,6 @@ struct irq_domain *__init aic_common_of_init(struct
> device_node *node,
>const struct irq_domain_ops *ops,
>const char *name, int nirqs);
>
> -void __init aic_common_rtc_irq_fixup(struct device_node *root);
> -
> void __init aic_common_rtt_irq_fixup(struct device_node *root);
>
> void __init aic_common_irq_fixup(const struct of_device_id *matches);
> diff --git a/drivers/irqchip/irq-atmel-aic.c b/drivers/irqchip/irq-atmel-aic.c
> index 8a0c7f2..4c60224 100644
> --- a/drivers/irqchip/irq-atmel-aic.c
> +++ b/drivers/irqchip/irq-atmel-aic.c
> @@ -209,11 +209,6 @@ static const struct irq_domain_ops aic_irq_ops = {
> .xlate = aic_irq_domain_xlate,
> };
>
> -static void __init at91rm9200_aic_irq_fixup(struct device_node *root)
> -{
> - aic_common_rtc_irq_fixup(root);
> -}
> -
> static void __init at91sam9260_aic_irq_fixup(struct device_node *root)
> {
> aic_common_rtt_irq_fixup(root);
> @@ -221,16 +216,12 @@ static void __init at91sam9260_aic_irq_fixup(struct
> device_node *root)
>
> static void __init at91sam9g45_aic_irq_fixup(struct device_node *root)
> {
> - aic_common_rtc_irq_fixup(root);
> aic_common_rtt_irq_fixup(root);
> }
>
> static const struct of_device_id aic_irq_fixups[] __initconst = {
> - { .compatible = "atmel,at91rm9200", .data = at91rm9200_aic_irq_fixup },
> { .compatible = "atmel,at91sam9g45", .data = at91sam9g45_aic_irq_fixup
> },
> - { .compatible = "atmel,at91sam9n
Re: [PATCH 03/19] irqchip: atmel-aic: clean up RTT interrupt code
On Mon, 4 Jan 2016 13:28:27 +0900
Milo Kim wrote:
> Atmel AIC disables RTT(Real Time Timer) interrupt on initialization.
> Alarm interrupt(ALMIEN) and RTT increment interrupt(RTTINCIEN) are used.
> However, the controller doesn't need to do it.
>
> * RTT driver disables interrupts on _probe().
> ALMIEN and RTTINCIEN bits in RTT_MR are cleared to disable RTT
> interrupts.
> (drivers/rtc/rtc-at91sam9.c)
> /* disable all interrupts (same as on shutdown path) */
> mr &= ~(AT91_RTT_ALMIEN | AT91_RTT_RTTINCIEN);
> rtt_writel(rtc, MR, mr);
>
> * All RTT interrupts are disabled by default.
> Reset value of ALMIEN and RTTINCIEN bits are 0.
> Please note that all devices have same RTT registers.
> AT91RM9G45
> AT91SAM9RL
> AT91SAM9260
> AT91SAM9261
> AT91SAM9263
> AT91SAM9G20
>
> So, aic_common_rtt_irq_fixup() helper can be removed.
> And aic_common_irq_fixup() also can be removed because no driver
> calls it any more.
Same as for patch 2, you cannot remove these functions without
impacting the system behavior.
>
> Cc: Thomas Gleixner
> Cc: Jason Cooper
> Cc: Marc Zyngier
> Cc: Alexandre Belloni
> Cc: Boris BREZILLON
> Cc: Ludovic Desroches
> Cc: Nicolas Ferre
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Milo Kim
> ---
> drivers/irqchip/irq-atmel-aic-common.c | 45
> --
> drivers/irqchip/irq-atmel-aic-common.h | 4 ---
> drivers/irqchip/irq-atmel-aic.c| 22 -
> 3 files changed, 71 deletions(-)
>
> diff --git a/drivers/irqchip/irq-atmel-aic-common.c
> b/drivers/irqchip/irq-atmel-aic-common.c
> index f8261be..ef2c619 100644
> --- a/drivers/irqchip/irq-atmel-aic-common.c
> +++ b/drivers/irqchip/irq-atmel-aic-common.c
> @@ -139,51 +139,6 @@ static void __init aic_common_ext_irq_of_init(struct
> irq_domain *domain)
> }
> }
>
> -#define AT91_RTT_MR 0x00/* Real-time Mode
> Register */
> -#define AT91_RTT_ALMIEN (1 << 16) /* Alarm
> Interrupt Enable */
> -#define AT91_RTT_RTTINCIEN (1 << 17) /* Real Time Timer
> Increment Interrupt Enable */
> -
> -void __init aic_common_rtt_irq_fixup(struct device_node *root)
> -{
> - struct device_node *np;
> - void __iomem *regs;
> -
> - /*
> - * The at91sam9263 SoC has 2 instances of the RTT block, hence we
> - * iterate over the DT to find each occurrence.
> - */
> - for_each_compatible_node(np, NULL, "atmel,at91sam9260-rtt") {
> - regs = of_iomap(np, 0);
> - if (!regs)
> - continue;
> -
> - writel(readl(regs + AT91_RTT_MR) &
> -~(AT91_RTT_ALMIEN | AT91_RTT_RTTINCIEN),
> -regs + AT91_RTT_MR);
> -
> - iounmap(regs);
> - }
> -}
> -
> -void __init aic_common_irq_fixup(const struct of_device_id *matches)
> -{
> - struct device_node *root = of_find_node_by_path("/");
> - const struct of_device_id *match;
> -
> - if (!root)
> - return;
> -
> - match = of_match_node(matches, root);
> - of_node_put(root);
> -
> - if (match) {
> - void (*fixup)(struct device_node *) = match->data;
> - fixup(root);
> - }
> -
> - of_node_put(root);
> -}
> -
> struct irq_domain *__init aic_common_of_init(struct device_node *node,
>const struct irq_domain_ops *ops,
>const char *name, int nirqs)
> diff --git a/drivers/irqchip/irq-atmel-aic-common.h
> b/drivers/irqchip/irq-atmel-aic-common.h
> index 9027f15..c178557 100644
> --- a/drivers/irqchip/irq-atmel-aic-common.h
> +++ b/drivers/irqchip/irq-atmel-aic-common.h
> @@ -32,8 +32,4 @@ struct irq_domain *__init aic_common_of_init(struct
> device_node *node,
>const struct irq_domain_ops *ops,
>const char *name, int nirqs);
>
> -void __init aic_common_rtt_irq_fixup(struct device_node *root);
> -
> -void __init aic_common_irq_fixup(const struct of_device_id *matches);
> -
> #endif /* __IRQ_ATMEL_AIC_COMMON_H */
> diff --git a/drivers/irqchip/irq-atmel-aic.c b/drivers/irqchip/irq-atmel-aic.c
> index 4c60224..6fcd680 100644
> --- a/drivers/irqchip/irq-atmel-aic.c
> +++ b/drivers/irqchip/irq-atmel-aic.c
> @@ -209,26 +209,6 @@ static const struct irq_domain_ops aic_irq_ops = {
> .xlate = aic_irq_domain_xlate,
> };
>
> -static void __init at91sam9260_aic_irq_fixup(struct device_node *root)
> -{
> - aic_common_rtt_irq_fixup(root);
> -}
> -
> -static void __init at91sam9g45_aic_irq_fixup(struct device_node *root)
> -{
> - aic_common_rtt_irq_fixup(root);
> -}
> -
> -static const struct of_device_id aic_irq_fixups[] __initconst = {
> - { .compatible = "atmel,at91sam9g45", .data = at91sam9g45_aic_irq_fixup
> },
> - { .compatible = "atmel,at91sam9rl", .data = at91sam9g45_aic_i
Re: [PATCH] drm: powerplay: use div64_s64 instead of do_div
On Fri, Jan 01, 2016 at 02:07:41PM +0100, Arnd Bergmann wrote:
> The newly added code for Fiji creates a correct compiler warning
> about invalid use of the do_div macro:
>
> In file included from powerplay/hwmgr/ppatomctrl.c:31:0:
> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppevvmath.h: In function
> 'fDivide':
> drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/ppevvmath.h:382:89: warning:
> comparison of distinct pointer types lacks a cast
> do_div(longlongX, longlongY); /*Q(32,32) divided by Q(16,16) = Q(16,16)
> Back to original format */
>
> do_div() divides an unsigned 64-bit number by an unsigned 32-bit number.
> The code instead wants to divide two signed 64-bit numbers, which is done
> using the div64_s64 function.
>
> Signed-off-by: Arnd Bergmann
> Fixes: 770911a3cfbb ("drm/amd/powerplay: add/update headers for Fiji SMU and
> DPM")
> ---
> Found on ARM allmodconfig on yesterday's linux-next
Reviewed-by: Thierry Reding
signature.asc
Description: PGP signature
Re: [PATCH 3/4] ALSA: hdac: use dev_to_hdac_dev
On Mon, Dec 28, 2015 at 10:47:12PM +0800, Geliang Tang wrote: > Use dev_to_hdac_dev() instead of open-coding it. > > Signed-off-by: Geliang Tang Reviewed-by: Vinod Koul Thanks -- ~Vinod -- 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 4/4] ASoC: hdac_hdmi: use dev_to_hdac_dev and to_ehdac_device
On Mon, Dec 28, 2015 at 10:47:13PM +0800, Geliang Tang wrote: > Use dev_to_hdac_dev() and to_ehdac_device() instead of open-coding. > Reviewed-by: Vinod Koul Thanks -- ~Vinod -- 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] ALSA: hdac: drop unused dev_to_hdac macro
On Mon, Dec 28, 2015 at 10:47:11PM +0800, Geliang Tang wrote:
> dev_to_hdac is not used anymore so drop it.
No harm in keeping this for now as the systems using these will be coming
up and more users will be upstreamed...
>
> Signed-off-by: Geliang Tang
> ---
> sound/hda/ext/hdac_ext_bus.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/sound/hda/ext/hdac_ext_bus.c b/sound/hda/ext/hdac_ext_bus.c
> index 2433f7c..58f6b98 100644
> --- a/sound/hda/ext/hdac_ext_bus.c
> +++ b/sound/hda/ext/hdac_ext_bus.c
> @@ -197,8 +197,6 @@ void snd_hdac_ext_bus_device_remove(struct hdac_ext_bus
> *ebus)
> }
> }
> EXPORT_SYMBOL_GPL(snd_hdac_ext_bus_device_remove);
> -#define dev_to_hdac(dev) (container_of((dev), \
> - struct hdac_device, dev))
>
> static inline struct hdac_ext_driver *get_edrv(struct device *dev)
> {
> --
> 2.5.0
>
>
--
~Vinod
--
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 4/3] drm: arm-hdlcd: add explictit DRM dependency
On Fri, Jan 01, 2016 at 11:04:07PM +0100, Arnd Bergmann wrote: > CONFIG_DRM_HDLCD is a tristate option that depends on the boolean > CONFIG_DRM_ARM, which in turn depends on the tristate CONFIG_DRM. > The effect of this is that a configuration with CONFIG_DRM=m > and CONFIG_DRM_HDLCD=y can be chosen, but won't link because the > DRM core symbols are not reachable from builtin code: > > drivers/built-in.o: In function `hdlcd_drm_unbind': > drivers/gpu/drm/arm/hdlcd_drv.c:445: undefined reference to > `drm_fbdev_cma_fini' > drivers/gpu/drm/arm/hdlcd_drv.c:448: undefined reference to > `drm_kms_helper_poll_fini' > drivers/gpu/drm/arm/hdlcd_drv.c:450: undefined reference to > `drm_vblank_cleanup' > drivers/gpu/drm/arm/hdlcd_drv.c:452: undefined reference to > `drm_irq_uninstall' > drivers/gpu/drm/arm/hdlcd_drv.c:460: undefined reference to > `drm_mode_config_cleanup' > drivers/gpu/drm/arm/hdlcd_drv.c:461: undefined reference to > `drm_dev_unregister' > drivers/gpu/drm/arm/hdlcd_drv.c:462: undefined reference to `drm_dev_unref' > ... > > This adds another dependency on CONFIG_DRM to enforce that DRM_HDLCD > cannot be builtin if DRM is not. Ugh... wouldn't it be much simpler to get rid of DRM_ARM? It seems like a completely superfluous option to me. I don't think we've ever had the equivalent of "vendor" Kconfig options in DRM, and I don't see why we'd need to start now. If ARM was going to add another driver it can simply have a separate Kconfig entry. There should be no need to select the vendor option first. Thierry signature.asc Description: PGP signature
Re: [PATCH 3/3] drm: arm-hdlcd: fix build warnings for !CONFIG_PM
On Fri, Jan 01, 2016 at 03:39:17PM +0100, Arnd Bergmann wrote: > The hdlcd_pm_suspend and hdlcd_pm_resume are intentionally unused > when CONFIG_PM is not set in this driver, and we get a compiler warning > for this: > > drivers/gpu/drm/arm/hdlcd_drv.c:521:12: warning: 'hdlcd_pm_suspend' defined > but not used [-Wunused-function] > drivers/gpu/drm/arm/hdlcd_drv.c:536:12: warning: 'hdlcd_pm_resume' defined > but not used [-Wunused-function] > > This adds a __maybe_unused annotation for the two functions, to let > the compiler know this is the intended behavior. This is better than > an #ifdef as it improves the compile time coverage of the code and it > looks nicer. > > Signed-off-by: Arnd Bergmann Reviewed-by: Thierry Reding signature.asc Description: PGP signature
Re: [PATCH 2/3] drm: arm-hdlcd: remove COMMON_CLK_SCPI select
On Fri, Jan 01, 2016 at 03:38:53PM +0100, Arnd Bergmann wrote: > The hdlcd driver has no build-time dependency on the SCPI clock > and the bogus 'select' causes a warning when SCPI is disabled: > > warning: (DRM_HDLCD) selects COMMON_CLK_SCPI which has unmet direct > dependencies (COMMON_CLK && (ARM_SCPI_PROTOCOL || COMPILE_TEST)) > > This removes the select statement. > > Signed-off-by: Arnd Bergmann > --- > Found two more bugs in the same driver, so this is now a patch series Reviewed-by: Thierry Reding signature.asc Description: PGP signature
Re: [PATCH] drm: arm-hdlcd: remove DMA_CMA select
On Fri, Jan 01, 2016 at 03:09:10PM +0100, Arnd Bergmann wrote:
> The newly added DRM_HDLCD driver tries to select DMA_CMA, but that is
> not necessarily possible, as not all configurations contain
> HAVE_DMA_CONTIGUOUS:
>
> warning: (DRM_HDLCD) selects DMA_CMA which has unmet direct dependencies
> (HAVE_DMA_CONTIGUOUS && CMA)
> drivers/built-in.o: In function `dma_alloc_from_contiguous':
> :(.text+0x1dee00): undefined reference to `cma_alloc'
> drivers/built-in.o: In function `dma_release_from_contiguous':
> :(.text+0x1dee24): undefined reference to `cma_release'
>
> This removes the 'select' statement. It is not needed because CMA is meant
> to transparently change the behavior of dma_alloc_coherent to make it succeed
> for larger allocations, but there is no actual build-time dependency, and
> the driver can still work without CMA in many cases.
>
> Signed-off-by: Arnd Bergmann
> Fixes: 1561e558334d ("drm: Add support for ARM's HDLCD controller.")
> ---
> Found on ARM randconfig builds with yesterday's linux-next
Reviewed-by: Thierry Reding
signature.asc
Description: PGP signature
Re: [PATCH 04/19] irqchip: atmel-aic: replace magic numbers with named constant
On Mon, 4 Jan 2016 13:28:28 +0900
Milo Kim wrote:
> One AIC IRQ chip can have 32 interrupt source.
> To enhance code readability, magic number is replaced with named constant,
> 'AIC_IRQS_PER_CHIP'.
>
> aic_hw_init() initializes vector registers up to total number of
> AIC interrupts. This magic number is replaced with NR_AIC_IRQS.
Actually this is a limitation of the generic chip infrastructure
(the irq_chip_generic uses u32 fields to store its internal status, and
each irq is attributed a bit position, which explains the 32 irqs per
chip limit), so I think this macro should be defined in
include/linux/irq.h:
#define MAX_IRQS_PER_GENERIC_CHIP 32
>
> Cc: Thomas Gleixner
> Cc: Jason Cooper
> Cc: Marc Zyngier
> Cc: Alexandre Belloni
> Cc: Boris BREZILLON
> Cc: Ludovic Desroches
> Cc: Nicolas Ferre
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Milo Kim
> ---
> drivers/irqchip/irq-atmel-aic-common.c | 11 ++-
> drivers/irqchip/irq-atmel-aic-common.h | 1 +
> drivers/irqchip/irq-atmel-aic.c| 2 +-
> drivers/irqchip/irq-atmel-aic5.c | 4 ++--
> 4 files changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/irqchip/irq-atmel-aic-common.c
> b/drivers/irqchip/irq-atmel-aic-common.c
> index ef2c619..5effd52 100644
> --- a/drivers/irqchip/irq-atmel-aic-common.c
> +++ b/drivers/irqchip/irq-atmel-aic-common.c
> @@ -135,7 +135,7 @@ static void __init aic_common_ext_irq_of_init(struct
> irq_domain *domain)
> }
>
> aic = gc->private;
> - aic->ext_irqs |= (1 << (hwirq % 32));
> + aic->ext_irqs |= (1 << (hwirq % AIC_IRQS_PER_CHIP));
> }
> }
>
> @@ -151,7 +151,7 @@ struct irq_domain *__init aic_common_of_init(struct
> device_node *node,
> int ret;
> int i;
>
> - nchips = DIV_ROUND_UP(nirqs, 32);
> + nchips = DIV_ROUND_UP(nirqs, AIC_IRQS_PER_CHIP);
>
> reg_base = of_iomap(node, 0);
> if (!reg_base)
> @@ -163,13 +163,14 @@ struct irq_domain *__init aic_common_of_init(struct
> device_node *node,
> goto err_iounmap;
> }
>
> - domain = irq_domain_add_linear(node, nchips * 32, ops, aic);
> + domain = irq_domain_add_linear(node, nchips * AIC_IRQS_PER_CHIP, ops,
> +aic);
> if (!domain) {
> ret = -ENOMEM;
> goto err_free_aic;
> }
>
> - ret = irq_alloc_domain_generic_chips(domain, 32, 1, name,
> + ret = irq_alloc_domain_generic_chips(domain, AIC_IRQS_PER_CHIP, 1, name,
>handle_fasteoi_irq,
>IRQ_NOREQUEST | IRQ_NOPROBE |
>IRQ_NOAUTOEN, 0, 0);
> @@ -177,7 +178,7 @@ struct irq_domain *__init aic_common_of_init(struct
> device_node *node,
> goto err_domain_remove;
>
> for (i = 0; i < nchips; i++) {
> - gc = irq_get_domain_generic_chip(domain, i * 32);
> + gc = irq_get_domain_generic_chip(domain, i * AIC_IRQS_PER_CHIP);
>
> gc->reg_base = reg_base;
>
> diff --git a/drivers/irqchip/irq-atmel-aic-common.h
> b/drivers/irqchip/irq-atmel-aic-common.h
> index c178557..4c0b471 100644
> --- a/drivers/irqchip/irq-atmel-aic-common.h
> +++ b/drivers/irqchip/irq-atmel-aic-common.h
> @@ -16,6 +16,7 @@
> #ifndef __IRQ_ATMEL_AIC_COMMON_H
> #define __IRQ_ATMEL_AIC_COMMON_H
>
> +#define AIC_IRQS_PER_CHIP32
>
> int aic_common_set_type(struct irq_data *d, unsigned type, unsigned *val);
>
> diff --git a/drivers/irqchip/irq-atmel-aic.c b/drivers/irqchip/irq-atmel-aic.c
> index 6fcd680..c499949 100644
> --- a/drivers/irqchip/irq-atmel-aic.c
> +++ b/drivers/irqchip/irq-atmel-aic.c
> @@ -164,7 +164,7 @@ static void __init aic_hw_init(struct irq_domain *domain)
> irq_reg_writel(gc, 0x, AT91_AIC_IDCR);
> irq_reg_writel(gc, 0x, AT91_AIC_ICCR);
>
> - for (i = 0; i < 32; i++)
> + for (i = 0; i < NR_AIC_IRQS; i++)
> irq_reg_writel(gc, i, AT91_AIC_SVR(i));
> }
>
> diff --git a/drivers/irqchip/irq-atmel-aic5.c
> b/drivers/irqchip/irq-atmel-aic5.c
> index 8b8f5e2..f5848c8 100644
> --- a/drivers/irqchip/irq-atmel-aic5.c
> +++ b/drivers/irqchip/irq-atmel-aic5.c
> @@ -306,9 +306,9 @@ static int __init aic5_of_init(struct device_node *node,
> return PTR_ERR(domain);
>
> aic5_domain = domain;
> - nchips = aic5_domain->revmap_size / 32;
> + nchips = aic5_domain->revmap_size / AIC_IRQS_PER_CHIP;
> for (i = 0; i < nchips; i++) {
> - gc = irq_get_domain_generic_chip(domain, i * 32);
> + gc = irq_get_domain_generic_chip(domain, i * AIC_IRQS_PER_CHIP);
>
> gc->chip_types[0].regs.eoi = AT91_AIC5_EOICR;
> gc->chip_types[0].chip.irq_mask = aic5_mask;
--
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
T
Re: [PATCH 05/19] irqchip: atmel-aic: use simple constant to get number of interrupts per chip
On Mon, 4 Jan 2016 13:28:29 +0900
Milo Kim wrote:
> Number of interrupts per each chip is determined when IRQ controller
> allocates IRQ chip by calling irq_alloc_domain_generic_chips().
> This number is fixed by atmel-aic-common part. The value is 32.
> So each AIC driver can use this value directly in IRQ chip operation.
Sorry, but I don't like the idea of hardcoding the number of irqs per
chip just to optimize some functions that are rarely called.
What if atmel creates a chip using the AIC but exposing less than 32
irqs? You'll have to change all those places.
Do you have a strong reason to do this kind of optimization?
>
> Cc: Thomas Gleixner
> Cc: Jason Cooper
> Cc: Marc Zyngier
> Cc: Alexandre Belloni
> Cc: Boris BREZILLON
> Cc: Ludovic Desroches
> Cc: Nicolas Ferre
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Milo Kim
> ---
> drivers/irqchip/irq-atmel-aic.c | 2 +-
> drivers/irqchip/irq-atmel-aic5.c | 9 +++--
> 2 files changed, 4 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/irqchip/irq-atmel-aic.c b/drivers/irqchip/irq-atmel-aic.c
> index c499949..f2c0fd9 100644
> --- a/drivers/irqchip/irq-atmel-aic.c
> +++ b/drivers/irqchip/irq-atmel-aic.c
> @@ -188,7 +188,7 @@ static int aic_irq_domain_xlate(struct irq_domain *d,
> if (ret)
> return ret;
>
> - idx = intspec[0] / dgc->irqs_per_chip;
> + idx = intspec[0] / AIC_IRQS_PER_CHIP;
> if (idx >= dgc->num_chips)
> return -EINVAL;
>
> diff --git a/drivers/irqchip/irq-atmel-aic5.c
> b/drivers/irqchip/irq-atmel-aic5.c
> index f5848c8..50d540b 100644
> --- a/drivers/irqchip/irq-atmel-aic5.c
> +++ b/drivers/irqchip/irq-atmel-aic5.c
> @@ -153,14 +153,13 @@ static int aic5_set_type(struct irq_data *d, unsigned
> type)
> static void aic5_suspend(struct irq_data *d)
> {
> struct irq_domain *domain = d->domain;
> - struct irq_domain_chip_generic *dgc = domain->gc;
> struct irq_chip_generic *bgc = irq_get_domain_generic_chip(domain, 0);
> struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
> int i;
> u32 mask;
>
> irq_gc_lock(bgc);
> - for (i = 0; i < dgc->irqs_per_chip; i++) {
> + for (i = 0; i < AIC_IRQS_PER_CHIP; i++) {
> mask = 1 << i;
> if ((mask & gc->mask_cache) == (mask & gc->wake_active))
> continue;
> @@ -177,14 +176,13 @@ static void aic5_suspend(struct irq_data *d)
> static void aic5_resume(struct irq_data *d)
> {
> struct irq_domain *domain = d->domain;
> - struct irq_domain_chip_generic *dgc = domain->gc;
> struct irq_chip_generic *bgc = irq_get_domain_generic_chip(domain, 0);
> struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
> int i;
> u32 mask;
>
> irq_gc_lock(bgc);
> - for (i = 0; i < dgc->irqs_per_chip; i++) {
> + for (i = 0; i < AIC_IRQS_PER_CHIP; i++) {
> mask = 1 << i;
> if ((mask & gc->mask_cache) == (mask & gc->wake_active))
> continue;
> @@ -201,13 +199,12 @@ static void aic5_resume(struct irq_data *d)
> static void aic5_pm_shutdown(struct irq_data *d)
> {
> struct irq_domain *domain = d->domain;
> - struct irq_domain_chip_generic *dgc = domain->gc;
> struct irq_chip_generic *bgc = irq_get_domain_generic_chip(domain, 0);
> struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
> int i;
>
> irq_gc_lock(bgc);
> - for (i = 0; i < dgc->irqs_per_chip; i++) {
> + for (i = 0; i < AIC_IRQS_PER_CHIP; i++) {
> irq_reg_writel(bgc, i + gc->irq_base, AT91_AIC5_SSR);
> irq_reg_writel(bgc, 1, AT91_AIC5_IDCR);
> irq_reg_writel(bgc, 1, AT91_AIC5_ICCR);
--
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 1/1] HID: multitouch: enable palm rejection if device implements confidence usage
Hi Allen, On Mon, Dec 21, 2015 at 10:45 AM, Allen Hung wrote: > On 12/18/2015 05:52 AM, Benjamin Tissoires wrote: >> On Thu, Nov 26, 2015 at 3:21 PM, Jiri Kosina wrote: >>> On Fri, 20 Nov 2015, Allen Hung wrote: >>> The usage Confidence is mandary to Windows Precision Touchpad devices. The appearance of this usage is checked in hidinput_connect but the quirk MT_QUIRK_VALID_IS_CONFIDENCE is not applied to device accordingly. Apply this quirk and also remove quirk MT_QUIRK_ALWAYS_VALID to enable palm rejection for the WIN 8 touchpad devices which have implemented usage Confidence in its input reports. Tested on Dell XPS 13 laptop. Signed-off-by: Allen Hung >>> Applied to for-4.5/multitouch. Thanks, >>> >> Allen, looks like the Dell XPS13 2015 (or was it the 2014?) has >> problems with your patch: >> https://bugzilla.redhat.com/show_bug.cgi?id=1292583 (we backported >> this change in the Fedora kernel 4.2.7). >> >> Would you mind checking that this patch does not create regressions on >> older series of laptops? >> >> Thanks in advance. >> >> Cheers, >> Benjamin > Hi Benjamin, > > It looks like a XPS13 2014 but I can confirm this with my colleagues who are > in charge of this product line. I don't mind checking this patch with more > older series of laptops. I will do it and let you know the status. Should I > also test the machines with Fedora 23, or just go with Ubuntu OS? The XPS > machines are shipped with Ubuntu. > Btw, the issue reporter said she/he cannot reproduce the issue (posted on > Dec. 18). > [Sorry for the late answer, but you guessed the holiday season did not help :)] I think I'll just ask the reporter to confirm he can not reproduce and then close the downstream bug. Unless other people complains, I think we can just keep the current state and wait :) Cheers, Benjamin -- 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] irqchip: omap-intc: add support for spurious irq handling
Hi Thomas, On Tuesday 15 December 2015 08:58 PM, Tony Lindgren wrote: > * Sekhar Nori [151215 06:26]: >> Under some conditions, irq sorting procedure used >> by INTC can go wrong resulting in a spurious irq >> getting reported. >> >> If this condition is not handled, it results in >> endless stream of: >> >> unexpected IRQ trap at vector 00 >> >> messages from ack_bad_irq() >> >> Handle the spurious interrupt condition in omap-intc >> driver to prevent this. >> >> Measurements using kernel function profiler on AM335x >> EVM running at 720MHz show that after this patch >> omap_intc_handle_irq() takes about 37.4us against >> 34us before this patch. >> >> Signed-off-by: Sekhar Nori > > Looks good to me, probably should get tagged Cc stable when > committing: > > Acked-by: Tony Lindgren Can you please apply this if it looks good? Thanks, Sekhar -- 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/2] phy: add a driver for the Rockchip SoC internal eMMC PHY
Hi Kishon,
On 2016/1/4 15:45, Kishon Vijay Abraham I wrote:
Hi,
On Tuesday 29 December 2015 07:22 AM, Shawn Lin wrote:
This patch to add a generic PHY driver for ROCKCHIP eMMC PHY.
[...]
+
+struct rockchip_emmc_phy {
+ unsigned intreg_offset;
+ struct regmap *reg_base;
+ struct phy *phy;
The phy looks unnecessary.
right, got it.
+ boolstate;
hmm.. I want to have some sort of state machine in phy core so that individual
PHY drivers don't have to maintain the state. However I'm not sure if all the
PHY's will require such mechanism.
In general, phy core is the best place to maintain it.
Presumably, phy driver maintainer is much likely to
maintain the corresponding caller driver at the same time, so he/she
should be in charge of maintaining the on/off, init/exit pairs. From
this point, it doesn't need the state machine. But, I'm not sure if the
caller driver will always keep the on/off pairs correct.
Anyway, I will remove it from this driver. And may we request a RFC
for all sub-phy drivers to discuss this issue if we want to add the
state machine into phy core. How about?
+};
+
+static int rockchip_emmc_phy_power(struct rockchip_emmc_phy *rk_phy,
[...]
+}
+
+static int rockchip_emmc_phy_init(struct phy *phy)
+{
+ rockchip_emmc_phy_power_on(phy);
do only phy initialization here, power on can be done later.
yep.
+ return 0;
+}
+
+static int rockchip_emmc_phy_exit(struct phy *phy)
+{
+ rockchip_emmc_phy_power_off(phy);
same here.
Thanks
Kishon
--
Best Regards
Shawn Lin
--
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] [media] si2165: Refactoring for si2165_writereg_mask8()
Am 27.12.2015 um 18:33 schrieb SF Markus Elfring: > From: Markus Elfring > Date: Sun, 27 Dec 2015 18:23:57 +0100 > > This issue was detected by using the Coccinelle software. > > 1. Let us return directly if a call of the si2165_readreg8() >function failed. > > 2. Reduce the scope for the local variables "ret" and "tmp" to one branch >of an if statement. > > 3. Delete the jump label "err" then. > > 4. Return the value from a call of the si2165_writereg8() function >without using an extra assignment for the variable "ret" at the end. > > Signed-off-by: Markus Elfring The patch looks fine. Signed-off-by: Matthias Schwarzott Regards Matthias PS: I am going to switch to regmap, but this change is not yet polished and until now does not touch this function. -- 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: Tree for Jan 4
Hi all, Changes since 20151231: Dropped tree: rdma (complex conflicts) New trees: drm-vc4, bcm2835-dt, bcm2835-soc, bcm2835-drivers, bcm2835-defconfig The ext4 tree gained a build failure so I used the version from next-20151231. The i2c tree still had its build failure for which I applied a patch. The libata tree was fixed up. The rdma tree still had its considerable conflicts against the nfsd tree, so I dropped the rdma tree again for today. The drm tree lost a build failure, but still had the other for which I added a fix patch. The rcu tree gained a build failure for which I reverted 2 commits. The integrity tree gained a conflict against the vfs tree. The akpm-current tree gained a conflict against the drm tree and a supplied patch for the perf build problem. The akpm tree lost a patch that turned up elsewhere but still had its build failure that I just left broken for now. Non-merge commits (relative to Linus' tree): 8627 8450 files changed, 411632 insertions(+), 156035 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig (this fails its final link) and pseries_le_defconfig and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 237 trees (counting Linus' and 36 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (9c982e86dbdb Merge tag 'pci-v4.4-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci) Merging fixes/master (25cb62b76430 Linux 4.3-rc5) Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on module install) Merging arc-current/for-curr (74bf8efb5fa6 Linux 4.4-rc7) Merging arm-current/fixes (34bfbae33ae8 ARM: 8475/1: SWP emulation: Restore original *data when failed) Merging m68k-current/for-linus (21d380e54c30 m68k: Wire up mlock2) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-fixes/fixes (036592fbbe75 powerpc/opal-irqchip: Fix deadlock introduced by "Fix double endian conversion") Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2) Merging sparc/master (9c982e86dbdb Merge tag 'pci-v4.4-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci) Merging net/master (9c982e86dbdb Merge tag 'pci-v4.4-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci) Merging ipsec/master (a8a572a6b5f2 xfrm: dst_entries_init() per-net dst_ops) Merging ipvs/master (8e662164abb4 netfilter: nfnetlink_queue: avoid harmless unnitialized variable warnings) Merging wireless-drivers/master (01d85b9b2b6b Merge tag 'iwlwifi-for-kalle-2015-12-16' of https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes) Merging mac80211/master (cf1e05c63642 mac80211: handle width changes from opmode notification IE in beacon) Merging sound-current/for-linus (c7b60a89516b ALSA: hda - Add keycode map for alc input device) Merging pci-current/for-linus (1dbe162d53e1 PCI: hisi: Fix hisi_pcie_cfg_read() 32-bit reads) Merging driver-core.current/driver-core-linus (4ef7675344d6 Linux 4.4-rc6) Merging tty.current/tty-linus (4ef7675344d6 Linux 4.4-rc6) Merging usb.current/usb-linus (4ef7675344d6 Linux 4.4-rc6) Merging usb-gadget-fixes/fixes (7d32cdef5356 usb: musb: fail with error when no DMA controller set) Merging usb-serial-fixes/usb-linus (f7d7f59ab124 USB: cp210x: add ID for ELV Marble Sound Board 1) Merging usb-chipidea-fixes/ci-for-usb-stable (6f51bc340d2a usb: chipidea: imx: fix a possible NULL
Re: [PATCH v6 0/9] mfd: axp20x: Add support for RSB based AXP223
Hi Lee, On Thu, Dec 17, 2015 at 12:32 AM, Chen-Yu Tsai wrote: > Hi everyone, > > This is v6 of the AXP223 PMIC series. v6 fixes the address of the AXP223 > in the DT. Hope this series makes it into 4.5, and we can then support > even more AXP PMICs in 4.6+. > > Lee, can you take the first 7 patches. Once they're in, Maxime can take > the DTS patches. We're at -rc8. Any chance the first 7 patches make the next release? Thanks ChenYu > > Changes since v5: > > - Correct AXP223 address to 0x3a3. > > Changes since v4: > > - Get rid of second parameter of axp20x_match_device() (new patch 2) > > - Match against dev->driver->of_match_table, so the entirety of > axp20x_match_device() can be kept in the core. (new patch 3) > > - Move *_device_id tables to bottom of the driver, right above driver > declaration. (patch 4 & 6) > > - Remove extra whitespaces while moving i2c specific code (patch 4) > > - Remove leftover whitespace and code style issues in axp20x core > (new patch 5) > > - Remove extra whitespaces in rsb specific code (patch 6) > > Changes since v3: > > - Removed settings for axp223 reg_rtc_ldo from board dts files that > are already in axp22x.dtsi. The name is kept. > > - Dropped simplefb label and defconfig patches, as they are merged. > > Changes since v2: > > - s/It's/Its/ for the commit messages of patches 5 and 7 > > - Add Rob's Acked-by for patch 1 > > Changes since v1: > > - Dropped NMI interrupt controller dts patch (Merged) > > - Change MFD_AXP20X to represent the axp20x core, and drop MFD_AXP20X_CORE > > - Keep the axp20x core bits named axp20x.c > > - Add patch 7 to add AXP223 to sun8i-q8-common.dtsi > > - Add patch 8 & 9 to update defconfigs > > - Make axp20x drivers tristate and buildable as modules > > - Drop "_sunxi" substring from identifiers in axp20x-rsb driver > > > This series adds support for the Reduced Serial Bus based AXP223 PMIC. > The AXP223 is functionally identical to the AXP221, which we already > support. Only some default values for the regulators are different. > The defaults fit their recommended application, paired with different > SoCs. > > Patch 1 adds AXP223 to the list of supported chips in the DT binding. > > Patch 2 gets rid of the extra "struct device *" parameter from > axp20x_match_device(). > > Patch 3 makes axp20x_match_device() use dev->driver->of_match_table, > so the function can be library-ized without modification. > > Patch 4 splits the axp20x mfd driver into 2 parts, a core library, and > an I2C driver. > > Patch 5 cleans up some leftover whitespace issues in axp20x core. > > Patch 6 adds an RSB based driver for the AXP223. > > Patch 7 adds support for the AXP223 regulators > > Patch 8 enables the AXP223 PMIC and its regulators for the Sinlinx > SinA33. > > Patch 9 enables the AXP223 PMIC and its regulators for A23/A33 based > Q8 tablet devices. > > > Regards > ChenYu > > > Chen-Yu Tsai (9): > mfd: axp20x: Add AXP223 to list of supported PMICs in DT bindings > mfd: axp20x: Remove second struct device * parameter for > axp20x_match_device() > mfd: axp20x: use dev->driver->of_match_table in axp20x_match_device() > mfd: axp20x: Split the driver into core and i2c bits > mfd: axp20x: Whitespace, open parenthesis alignment code style fixes > mfd: axp20x: Add support for RSB based AXP223 PMIC > regulator: axp20x: Support new AXP223 PMIC > ARM: dts: sun8i: sinlinx-sina33: Add AXP223 PMIC device and regulator > nodes > ARM: dts: sun8i: q8-common: Add AXP223 PMIC device and regulator nodes > > Documentation/devicetree/bindings/mfd/axp20x.txt | 7 +- > arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 76 - > arch/arm/boot/dts/sun8i-q8-common.dtsi | 83 +- > drivers/mfd/Kconfig | 25 -- > drivers/mfd/Makefile | 2 + > drivers/mfd/axp20x-i2c.c | 102 > +++ > drivers/mfd/axp20x-rsb.c | 78 + > drivers/mfd/axp20x.c | 101 +- > drivers/regulator/axp20x-regulator.c | 3 + > include/linux/mfd/axp20x.h | 34 +++- > 10 files changed, 418 insertions(+), 93 deletions(-) > create mode 100644 drivers/mfd/axp20x-i2c.c > create mode 100644 drivers/mfd/axp20x-rsb.c > > -- > 2.6.4 > -- 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 4/3] drm: arm-hdlcd: add explictit DRM dependency
On Monday 04 January 2016 09:24:16 Thierry Reding wrote: > > Ugh... wouldn't it be much simpler to get rid of DRM_ARM? It seems like > a completely superfluous option to me. I don't think we've ever had the > equivalent of "vendor" Kconfig options in DRM, and I don't see why we'd > need to start now. If ARM was going to add another driver it can simply > have a separate Kconfig entry. There should be no need to select the > vendor option first. Fine with me too. I vaguely remembered having seen some discussion about this, so I decided to do a minimal fix, but I agree that would be more in line with the other drivers. 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: [PATCH 08/19] irqchip: atmel-aic: add common mask and unmask functions
On Mon, 4 Jan 2016 13:28:32 +0900
Milo Kim wrote:
> AIC has one register access to enable/disable an interrupt.
> AIC5 requires two register accesses - SSR and IECR/IDCR.
> This patch unifies interrupt mask and unmask operations.
>
> Mask and unmask operations are moved into aic_common_of_init().
> AIC5 can have multiple IRQ chips, mask/unmask should be assigned per chip.
> In case of AIC, it's also good because AIC has one IRQ chip.
> So looping count is just one time to configure mask/unmask functions.
>
> struct irq_domain *__init aic_common_of_init(struct device_node *node,
>const char *name, int nirqs)
> {
> ...
>
> for (i = 0; i < nchips; i++) {
> gc = irq_get_domain_generic_chip(domain, i * AIC_IRQS_PER_CHIP);
>
> ...
> gc->chip_types[0].chip.irq_mask = aic_mask;
> gc->chip_types[0].chip.irq_unmask = aic_unmask;
> gc->private = &aic[i];
> }
> }
>
> In AIC, register configuration for enabling and disabling IRQ can be
> replaced with irq_mask and irq_unmask. This is for using unified mask and
> unmask functions (aic_mask and aic_unmask).
>
> Cc: Thomas Gleixner
> Cc: Jason Cooper
> Cc: Marc Zyngier
> Cc: Alexandre Belloni
> Cc: Boris BREZILLON
> Cc: Ludovic Desroches
> Cc: Nicolas Ferre
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Milo Kim
> ---
> drivers/irqchip/irq-atmel-aic-common.c | 52
> ++
> drivers/irqchip/irq-atmel-aic.c| 4 ---
> drivers/irqchip/irq-atmel-aic5.c | 36 ---
> 3 files changed, 52 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/irqchip/irq-atmel-aic-common.c
> b/drivers/irqchip/irq-atmel-aic-common.c
> index 94c9dad..533b3e9 100644
> --- a/drivers/irqchip/irq-atmel-aic-common.c
> +++ b/drivers/irqchip/irq-atmel-aic-common.c
> @@ -193,6 +193,56 @@ static void aic_common_shutdown(struct irq_data *d)
> ct->chip.irq_mask(d);
> }
>
> +static void aic_mask(struct irq_data *d)
> +{
> + struct irq_domain *domain = d->domain;
> + struct irq_chip_generic *bgc = irq_get_domain_generic_chip(domain, 0);
> + struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
> + u32 mask = d->mask;
> +
> + /*
> + * Disable interrupt. We always take the lock of the
> + * first irq chip as all chips share the same registers.
> + */
> + irq_gc_lock(bgc);
> +
> + if (aic_is_ssr_used()) {
> + irq_reg_writel(gc, d->hwirq, aic_reg_data->ssr);
> + irq_reg_writel(gc, 1, aic_reg_data->idcr);
> + } else {
> + irq_reg_writel(gc, mask, aic_reg_data->idcr);
> + }
> +
> + gc->mask_cache &= ~mask;
> +
> + irq_gc_unlock(bgc);
> +}
> +
> +static void aic_unmask(struct irq_data *d)
> +{
> + struct irq_domain *domain = d->domain;
> + struct irq_chip_generic *bgc = irq_get_domain_generic_chip(domain, 0);
> + struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
> + u32 mask = d->mask;
> +
> + /*
> + * Enable interrupt. We always take the lock of the
> + * first irq chip as all chips share the same registers.
> + */
> + irq_gc_lock(bgc);
> +
> + if (aic_is_ssr_used()) {
> + irq_reg_writel(gc, d->hwirq, aic_reg_data->ssr);
> + irq_reg_writel(gc, 1, aic_reg_data->iecr);
> + } else {
> + irq_reg_writel(gc, mask, aic_reg_data->iecr);
> + }
In other words, you prefer to add extra conditional statements in the
critical irq path rather than keeping two different drivers for two IPs
that are not so similar.
Here is my opinion: if you want to get rid of the aic-common* files,
fine, but please keep 2 different drivers for the AIC and AIC5 IPs and
duplicate the common code in each driver.
I understand that code factorization is important (and this is exactly
why I created aic-common), but it's pointless to try to factorize things
that are completely different, and AIC and AIC5 fall in this case (look
at the number of aic_is_ssr_used() you're adding in your series).
--
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: Re: [PATCH] Input: evdev - drop partial events after emptying the buffer
On Mon, Jan 4, 2016 at 8:50 AM, Aniroop Mathur wrote: > On Jan 4, 2016 5:08 AM, "Peter Hutterer" wrote: >> >> On Sat, Jan 02, 2016 at 08:39:21PM -0800, Dmitry Torokhov wrote: >> > On Thu, Dec 31, 2015 at 03:36:47AM +0530, Aniroop Mathur wrote: >> > > This patch introduces concept to drop partial events in evdev handler >> > > itself after emptying the buffer which are dropped by all evdev >> > > clients in userspace after SYN_DROPPED occurs. >> > > This in turn saves space of partial events in evdev handler buffer >> > > and reduces evdev client reading requests. >> > >> > Let's add a few people who write consumer code to see if this is >> > something that they consider useful. >> >> yeah, it's useful though we already have the code in libevdev to work around >> this. Still, it reduces the number of events discarde by the client, so >> it'll be a net >> plus. but, afaict, there's a bug in this implementation. >> The doc states: "Client should ignore all events up to and including next >> SYN_REPORT event". If you drop partial events, you need to have an empty >> SYN_REPORT after the SYN_DROPPED before you start with full events again. >> This patch skips that, so after the SYN_DROPPED you have a valid full event >> that will be ignored by any client currently capable of handling >> SYN_DROPPED. >> Example: let's assume a device sending ABS_X/ABS_Y fast enough to cause a >> SYN_DROPPED, you may have this queue: >> ABS_X >> ABS_Y >> SYN_REPORT >> ... >> SYN_DROPPED >> ABS_Y < partial event >> SYN_REPORT < client discards up to here, sync state >> ABS_X >> ABS_Y >> SYN_REPORT < first full event after sync >> >> With this patch this sequence becomes: >> ABS_X >> ABS_Y >> SYN_REPORT >> ... >> SYN_DROPPED >> [kernel discards ABS_Y + SYN_REPORT as partial event] >> ABS_X >> ABS_Y >> SYN_REPORT <--- client discards up to here, sync state >><--- there is no event after sync >> >> That's a change in kernel behaviour and will make all current clients >> potentially buggy, you'll really need the empty SYN_REPORT here. >> > > Thank you for your input, Mr. Peter. > Actually, there is a need to update the documentation as well after this patch > so that clients no more ignore the events after SYN_DROPPED occurs and > should read the events normally. I skipped updating the documentation in > this patch as I thought of getting a consent first. > * SYN_DROPPED: > - Used to indicate buffer overrun in the evdev client's event queue. > Client should ignore all events up to and including next SYN_REPORT > event and query the device (using EVIOCG* ioctls) to obtain its > current state > + From kernel version <4.4.x> onwards, clients do no need to ignore > + events anymore and should read normally as there will be no > + partial events after SYN_DROPPED occurs. Hi Aniroop, this just won't do. As Peter said, there are current implementation of SYN_DROPPED around, which ignore the events until the next SYN_REPORT. If you change the protocol by updating the doc, you will just break existing userspace which has not included a check on the kernel version (and honestly, checking the kernel version from the userspace point of view is just a nightmare when distributions start backporting changes here and there). The kernel rule is "do not break userspace", so we can not accept this. Peter suggested you just add an empty SYN_REPORT after SYN_DROPPED which would solve the whole problem: clients already handling SYN_DROPPED will receive the next valid event, and those who don't (or which will be updated) will not have to do anything more. The only cons I can think of is that multitouch protocol A will be a pain to handle with this empty SYN_REPORT if you do not handle the SYN_DROPPED as per the doc. But on the other hand, if you have a MT protocol A device, you are screwed anyway because you need mtdev and so let's use libevdev at this point. > > As far as I've worked on client codes, this client code change is easy and Nope, checking the kernel version is not "easy" as this is not reliable. > even if some clients miss to update the code then it seems not much of > a problem because 8 packets are already dropped so an additional packet > would not cause any trouble in case of buffer overrun. Nope again. In case of a SYN_DROPPED, the client syncs its internal state by using ioctls. So if you drop one valid event, you are not in sync again and the SYN_DROPPED is moot. Cheers, Benjamin > > Regards, > Aniroop Mathur > >> > > >> > > Signed-off-by: Aniroop Mathur >> > > --- >> > > drivers/input/evdev.c | 49 >> > > + >> > > 1 file changed, 45 insertions(+), 4 deletions(-) >> > > >> > > diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c >> > > index e9ae3d5..e7b612e 100644 >> > > --- a/drivers/input/evdev.c >> > > +++ b/drivers/input/evdev.
Re: [PATCH 06/19] irqchip: atmel-aic: introduce register data structure
On Mon, 4 Jan 2016 13:28:30 +0900
Milo Kim wrote:
> Structure, 'aic_reg_offset' describes for device specific register offset.
> Each offset is used for IRQ chip operation. AIC and AIC5 have different
> register values, but the structure can be shared.
>
> Please note that this is not complete patch, it's a preceding step for
> making unified AIC driver.
>
> Cc: Thomas Gleixner
> Cc: Jason Cooper
> Cc: Marc Zyngier
> Cc: Alexandre Belloni
> Cc: Boris BREZILLON
> Cc: Ludovic Desroches
> Cc: Nicolas Ferre
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Milo Kim
> ---
> drivers/irqchip/irq-atmel-aic-common.c | 91
> ++
> 1 file changed, 91 insertions(+)
>
> diff --git a/drivers/irqchip/irq-atmel-aic-common.c
> b/drivers/irqchip/irq-atmel-aic-common.c
> index 5effd52..f840165 100644
> --- a/drivers/irqchip/irq-atmel-aic-common.c
> +++ b/drivers/irqchip/irq-atmel-aic-common.c
> @@ -24,6 +24,32 @@
>
> #include "irq-atmel-aic-common.h"
>
> +#define AT91_AIC_SMR_BASE0
> +#define AT91_AIC_SVR_BASE0x80
> +#define AT91_AIC_IVR 0x100
> +#define AT91_AIC_ISR 0x108
> +#define AT91_AIC_IECR0x120
> +#define AT91_AIC_IDCR0x124
> +#define AT91_AIC_ICCR0x128
> +#define AT91_AIC_ISCR0x12c
> +#define AT91_AIC_EOICR 0x130
> +#define AT91_AIC_SPU 0x134
> +#define AT91_AIC_DCR 0x138
> +#define AT91_INVALID_OFFSET (-1)
> +
> +#define AT91_AIC5_SSR0x0
> +#define AT91_AIC5_SMR0x4
> +#define AT91_AIC5_SVR0x8
> +#define AT91_AIC5_IVR0x10
> +#define AT91_AIC5_ISR0x18
> +#define AT91_AIC5_EOICR 0x38
> +#define AT91_AIC5_SPU0x3c
> +#define AT91_AIC5_IECR 0x40
> +#define AT91_AIC5_IDCR 0x44
> +#define AT91_AIC5_ICCR 0x48
> +#define AT91_AIC5_ISCR 0x4c
> +#define AT91_AIC5_DCR0x6c
> +
> #define AT91_AIC_PRIOR GENMASK(2, 0)
> #define AT91_AIC_IRQ_MIN_PRIORITY0
> #define AT91_AIC_IRQ_MAX_PRIORITY7
> @@ -38,6 +64,71 @@ struct aic_chip_data {
> u32 ext_irqs;
> };
>
> +/**
> + * struct aic_reg_offset
> + *
> + * @eoi: End of interrupt command register
> + * @smr: Source mode register
> + * @ssr: Source select register
> + * @iscr:Interrupt set command register
> + * @idcr:Interrupt disable command register
> + * @iccr:Interrupt clear command register
> + * @iecr:Interrupt enable command register
> + * @spu: Spurious interrupt vector register
> + * @dcr: Debug control register
> + * @svr: Source vector register
> + * @ivr: Interrupt vector register
> + * @isr: Interrupt status register
> + *
> + * Each value means register offset.
> + */
> +struct aic_reg_offset {
> + int eoi;
> + int smr;
> + int ssr;
> + int iscr;
> + int idcr;
> + int iccr;
> + int iecr;
> + int spu;
> + int dcr;
> + int svr;
> + int ivr;
> + int isr;
> +};
> +
> +static const struct aic_reg_offset aic_regs = {
> + .eoi= AT91_AIC_EOICR,
> + .smr= AT91_AIC_SMR_BASE,
> + .ssr= AT91_INVALID_OFFSET, /* No SSR exists */
> + .iscr = AT91_AIC_ISCR,
> + .idcr = AT91_AIC_IDCR,
> + .iccr = AT91_AIC_ICCR,
> + .iecr = AT91_AIC_IECR,
> + .spu= AT91_AIC_SPU,
> + .dcr= AT91_AIC_DCR,
> + .svr= AT91_AIC_SVR_BASE,
> + .ivr= AT91_AIC_IVR,
> + .isr= AT91_AIC_ISR,
> +};
> +
> +static const struct aic_reg_offset aic5_regs = {
> + .eoi= AT91_AIC5_EOICR,
> + .smr= AT91_AIC5_SMR,
> + .ssr= AT91_AIC5_SSR,
> + .iscr = AT91_AIC5_ISCR,
> + .idcr = AT91_AIC5_IDCR,
> + .iccr = AT91_AIC5_ICCR,
> + .iecr = AT91_AIC5_IECR,
> + .spu= AT91_AIC5_SPU,
> + .dcr= AT91_AIC5_DCR,
> + .svr= AT91_AIC5_SVR,
> + .ivr= AT91_AIC5_IVR,
> + .isr= AT91_AIC5_ISR,
> +};
> +
> +static const struct aic_reg_offset *aic_reg_data;
> +
Can we avoid adding this global variable: this information can probably
be added to the aic_chip_data struct.
> static void aic_common_shutdown(struct irq_data *d)
> {
> struct irq_chip_type *ct = irq_data_get_chip_type(d);
--
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 V9 1/2] ACPI, PCI, irq: remove interrupt count restriction
On Fri, Jan 1, 2016 at 2:48 AM, Rafael J. Wysocki wrote: > On Wednesday, December 30, 2015 09:55:35 PM Andy Shevchenko wrote: >> On Wed, Dec 30, 2015 at 9:17 PM, Sinan Kaya wrote: >> > On 12/30/2015 8:28 AM, Andy Shevchenko wrote: >> >> Yep, I meant not to use an additional variable. >> >> >> >>> > BTW, I suggest you spend some time around checkpatch for >> >>> > contributions. I could >> >>> > have caught most of the issues you are generally concerned before >> >>> > submitting a patch. >> >> Is it a question? >> > >> > It is a request not a question. I hate wasting your time and my time with >> > things that I could >> > have fixed before submitting a patch. >> > >> > I ran the checkpatch and it said I'm good to go. But, obviously I'm not. >> >> Hmm… checkpatch.pl is just a small helper to fix style issues. Here is >> just a common sense rule, or kind of Occam's razor: no need to have >> more variables then needed if it doesn't improve something really >> significantly. > > That said, compilers optimize things anyway, so using an extra local variable > shouldn't matter for the resulting machine code. I'm not totally against that, but is the additional variable helpful here? -- With Best Regards, Andy Shevchenko -- 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 v3 net-next] net: ethernet: cadence-macb: Add disabled usrio caps
On some platforms, the macb integration does not use the USRIO
register to configure the (R)MII port and clocks.
When the register is not implemented and the MACB error signal
is connected to the bus error, reading or writing to the USRIO
register can trigger some Imprecise External Aborts on ARM platforms.
Signed-off-by: Neil Armstrong
---
drivers/net/ethernet/cadence/macb.c | 27 +++
drivers/net/ethernet/cadence/macb.h | 1 +
2 files changed, 16 insertions(+), 12 deletions(-)
Nicolas,
I post only the first patch of the previous set posted here :
http://lkml.kernel.org/r/1449582726-6148-1-git-send-email-narmstr...@baylibre.com
to hopefully make it into the 4.5 merge time,
I'll post the vendor prefix once this patch will hit mainline.
Regards,
Neil
diff --git a/drivers/net/ethernet/cadence/macb.c
b/drivers/net/ethernet/cadence/macb.c
index 8b45bc9..fa53bc3 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -2124,7 +2124,8 @@ static void macb_get_regs(struct net_device *dev, struct
ethtool_regs *regs,
regs_buff[10] = macb_tx_dma(&bp->queues[0], tail);
regs_buff[11] = macb_tx_dma(&bp->queues[0], head);
- regs_buff[12] = macb_or_gem_readl(bp, USRIO);
+ if (!(bp->caps & MACB_CAPS_USRIO_DISABLED))
+ regs_buff[12] = macb_or_gem_readl(bp, USRIO);
if (macb_is_gem(bp)) {
regs_buff[13] = gem_readl(bp, DMACFG);
}
@@ -2403,19 +2404,21 @@ static int macb_init(struct platform_device *pdev)
dev->hw_features &= ~NETIF_F_SG;
dev->features = dev->hw_features;
- val = 0;
- if (bp->phy_interface == PHY_INTERFACE_MODE_RGMII)
- val = GEM_BIT(RGMII);
- else if (bp->phy_interface == PHY_INTERFACE_MODE_RMII &&
-(bp->caps & MACB_CAPS_USRIO_DEFAULT_IS_MII))
- val = MACB_BIT(RMII);
- else if (!(bp->caps & MACB_CAPS_USRIO_DEFAULT_IS_MII))
- val = MACB_BIT(MII);
+ if (!(bp->caps & MACB_CAPS_USRIO_DISABLED)) {
+ val = 0;
+ if (bp->phy_interface == PHY_INTERFACE_MODE_RGMII)
+ val = GEM_BIT(RGMII);
+ else if (bp->phy_interface == PHY_INTERFACE_MODE_RMII &&
+(bp->caps & MACB_CAPS_USRIO_DEFAULT_IS_MII))
+ val = MACB_BIT(RMII);
+ else if (!(bp->caps & MACB_CAPS_USRIO_DEFAULT_IS_MII))
+ val = MACB_BIT(MII);
- if (bp->caps & MACB_CAPS_USRIO_HAS_CLKEN)
- val |= MACB_BIT(CLKEN);
+ if (bp->caps & MACB_CAPS_USRIO_HAS_CLKEN)
+ val |= MACB_BIT(CLKEN);
- macb_or_gem_writel(bp, USRIO, val);
+ macb_or_gem_writel(bp, USRIO, val);
+ }
/* Set MII management clock divider */
val = macb_mdc_clk_div(bp);
diff --git a/drivers/net/ethernet/cadence/macb.h
b/drivers/net/ethernet/cadence/macb.h
index 5c03e81..0d4ecfc 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -400,6 +400,7 @@
#define MACB_CAPS_USRIO_HAS_CLKEN 0x0002
#define MACB_CAPS_USRIO_DEFAULT_IS_MII 0x0004
#define MACB_CAPS_NO_GIGABIT_HALF 0x0008
+#define MACB_CAPS_USRIO_DISABLED 0x0010
#define MACB_CAPS_FIFO_MODE0x1000
#define MACB_CAPS_GIGABIT_MODE_AVAILABLE 0x2000
#define MACB_CAPS_SG_DISABLED 0x4000
--
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 00/19] irqchip: atmel-aic: make unified AIC driver
Hi Milo, On Mon, 4 Jan 2016 13:28:24 +0900 Milo Kim wrote: > This patch-set provides unified Atmel AIC (Advanced Interrupt Controller) > driver. Currently, there are two AIC drivers, AIC and AIC5. > Each driver consists of chip specific part (irq-atmel-aic.o or > irq-atmel-aic5.o) and shared code (irq-atmel-aic-common.o). > But consolidated AIC driver is just one file driver which supports both > IRQ chip systems. Sorry, but what's the real motivation behind this rework? > > How to handle two IRQ chips in one driver > - > Structure aic_reg_offset is used for device configuration. > AIC5 IRQ chip uses SSR (Source Select Register) to select IRQ number. > On the other hand, AIC IRQ chip has simple register access. > To support both IRQ chips, aic_is_ssr_used() helper is used. > > Patches > --- > 1 ~ 5: fix IRQ priority issue, clean up RTC/RTT fixup code and etc. As explained in my review, those irq fixup are essential, and cannot remove them. > 6 ~ 19: create unified IRQ chip operation with aic_reg_offset data. I started to review those patches, but honestly I don't see the point of this rework, since you're trying to merge drivers for 2 IPs that are completely different from a functional POV (except for a few tiny things like priority or irq type definition). Before reviewing the remaining patches, I'd like to know more about your real motivations for pushing those changes? > > Target boards > - > Tested with two boards. > * Arietta G25 (SoC: AT91SAM9G25) > * Xplained board (SoC: SAMA5D3) > > Number of driver files > -- > AIC: 3 (irq-atmel-aic.c, irq-atmel-aic-common.c and h) > AIC5: 3 (irq-atmel-aic5.c, irq-atmel-aic-common.c and h) > Consolidated AIC: 1 (irq-aic.c) > > Code size > - > AIC (irq-atmel-aic.o and irq-atmel-aic-common.o) > text data bss dec hex filename > 5137 196 4533714d9 drivers/irqchip/built-in.o > > AIC5 (irq-atmel-aic5.o and irq-atmel-aic-common.o) > text data bss dec hex filename > 5548 196 457481674 drivers/irqchip/built-in.o > > Consolidated AIC (irq-aic.o) > text data bss dec hex filename > 4841 196 8504513b5 drivers/irqchip/built-in.o > > Lines of code > - > AIC: 597 > AIC5: 688 > Consolidated AIC: 609 Please, redo the same thing, but after keeping the IRQ fixup stuff, and I'm pretty sure the text section of the AIC/AIC5 and the consolidated version will be much closer. Not to mention that you're adding a bunch of if () statements in the critical IRQ path, which is never a good think for latency concern. Best Regards, Boris > > Milo Kim (19): > irqchip: atmel-aic: fix wrong bit operation for IRQ priority > irqchip: atmel-aic: clean up RTC interrupt code > irqchip: atmel-aic: clean up RTT interrupt code > irqchip: atmel-aic: replace magic numbers with named constant > irqchip: atmel-aic: use simple constant to get number of interrupts > per chip > irqchip: atmel-aic: introduce register data structure > irqchip: atmel-aic: make common IRQ domain translate function > irqchip: atmel-aic: add common mask and unmask functions > irqchip: atmel-aic: add common retrigger function > irqchip: atmel-aic: add common set_type function > irqchip: atmel-aic: add common PM IRQ chip operation > irqchip: atmel-aic: use EOI register data in aic_reg_data > irqchip: atmel-aic: clean up irq_chip_generic > irqchip: atmel-aic: add common HW init function > irqchip: atmel-aic: add common interrupt handler > irqchip: atmel-aic: get total number of IRQs from device node > irqchip: atmel-aic: use unified IRQ chip initialization function > irqchip: atmel-aic: use unified AIC driver > irqchip: atmel-aic: rename AIC driver and fix Kconfig > > arch/arm/mach-at91/Kconfig | 2 +- > drivers/irqchip/Kconfig| 7 - > drivers/irqchip/Makefile | 3 +- > drivers/irqchip/irq-aic.c | 609 > + > drivers/irqchip/irq-atmel-aic-common.c | 280 --- > drivers/irqchip/irq-atmel-aic-common.h | 41 --- > drivers/irqchip/irq-atmel-aic.c| 276 --- > drivers/irqchip/irq-atmel-aic5.c | 367 > 8 files changed, 611 insertions(+), 974 deletions(-) > create mode 100644 drivers/irqchip/irq-aic.c > delete mode 100644 drivers/irqchip/irq-atmel-aic-common.c > delete mode 100644 drivers/irqchip/irq-atmel-aic-common.h > delete mode 100644 drivers/irqchip/irq-atmel-aic.c > delete mode 100644 drivers/irqchip/irq-atmel-aic5.c > -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -- To unsubscribe from this list: send the line "unsubscribe linux-ker
Re: [PATCH] ext2, ext4: include filesystem block size in error messages
On Wed 23-12-15 18:10:01, Robert Elliott wrote:
> Print the problematic value in messages about the filesystem
> block size.
>
> Normalize all of the blocksize messages that use "blocksize" to
> use "filesystem block size". This helps distinguish this block size
> from the underlying block device's logical block size (i.e.,
> sector size) and physical block size.
>
> Example old messages:
> EXT2-fs (pmem0): unable to set blocksize
> EXT4-fs (pmem0): error: unsupported blocksize for dax
> EXT4-fs (pmem0): unsupported blocksize for fs encryption
> EXT2-fs (pmem0): bad blocksize %d
>
> Example new message:
> EXT4-fs (pmem0): error: unsupported filesystem block size 2048 for dax
Looks good to me. You can add:
Reviewed-by: Jan Kara
Honza
>
> Signed-off-by: Robert Elliott
> ---
> fs/ext2/super.c | 17 +++--
> fs/ext4/super.c | 33 -
> 2 files changed, 31 insertions(+), 19 deletions(-)
>
> diff --git a/fs/ext2/super.c b/fs/ext2/super.c
> index 748d35a..1186a5b 100644
> --- a/fs/ext2/super.c
> +++ b/fs/ext2/super.c
> @@ -31,6 +31,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include "ext2.h"
> #include "xattr.h"
> @@ -822,7 +823,9 @@ static int ext2_fill_super(struct super_block *sb, void
> *data, int silent)
>*/
> blocksize = sb_min_blocksize(sb, BLOCK_SIZE);
> if (!blocksize) {
> - ext2_msg(sb, KERN_ERR, "error: unable to set blocksize");
> + ext2_msg(sb, KERN_ERR,
> + "error: unable to set filesystem block size "
> + __stringify(BLOCK_SIZE));
> goto failed_sbi;
> }
>
> @@ -921,7 +924,8 @@ static int ext2_fill_super(struct super_block *sb, void
> *data, int silent)
> if (sbi->s_mount_opt & EXT2_MOUNT_DAX) {
> if (blocksize != PAGE_SIZE) {
> ext2_msg(sb, KERN_ERR,
> - "error: unsupported blocksize for dax");
> + "error: unsupported filesystem block size %d for dax",
> + blocksize);
> goto failed_mount;
> }
> if (!sb->s_bdev->bd_disk->fops->direct_access) {
> @@ -937,7 +941,7 @@ static int ext2_fill_super(struct super_block *sb, void
> *data, int silent)
>
> if (!sb_set_blocksize(sb, blocksize)) {
> ext2_msg(sb, KERN_ERR,
> - "error: bad blocksize %d", blocksize);
> + "error: bad filesystem block size %d", blocksize);
> goto failed_sbi;
> }
>
> @@ -1007,14 +1011,15 @@ static int ext2_fill_super(struct super_block *sb,
> void *data, int silent)
>
> if (sb->s_blocksize != bh->b_size) {
> if (!silent)
> - ext2_msg(sb, KERN_ERR, "error: unsupported blocksize");
> + ext2_msg(sb, KERN_ERR,
> + "error: unsupported filesystem block size %lu",
> + sb->s_blocksize);
> goto failed_mount;
> }
>
> if (sb->s_blocksize != sbi->s_frag_size) {
> ext2_msg(sb, KERN_ERR,
> - "error: fragsize %lu != blocksize %lu"
> - "(not supported yet)",
> + "error: fragsize %lu != filesystem block size %lu (not supported yet)",
> sbi->s_frag_size, sb->s_blocksize);
> goto failed_mount;
> }
> diff --git a/fs/ext4/super.c b/fs/ext4/super.c
> index c9ab67d..9e1c049 100644
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@ -42,6 +42,7 @@
>
> #include
> #include
> +#include
>
> #include "ext4.h"
> #include "ext4_extents.h"/* Needed for trace points definition */
> @@ -1750,8 +1751,9 @@ static int parse_options(char *options, struct
> super_block *sb,
> BLOCK_SIZE << le32_to_cpu(sbi->s_es->s_log_block_size);
>
> if (blocksize < PAGE_CACHE_SIZE) {
> - ext4_msg(sb, KERN_ERR, "can't mount with "
> - "dioread_nolock if block size != PAGE_SIZE");
> + ext4_msg(sb, KERN_ERR,
> + "can't mount with dioread_nolock if filesystem
> block size %d != PAGE_SIZE",
> + blocksize);
> return 0;
> }
> }
> @@ -3147,7 +3149,9 @@ static int ext4_fill_super(struct super_block *sb, void
> *data, int silent)
> ret = -EINVAL;
> blocksize = sb_min_blocksize(sb, EXT4_MIN_BLOCK_SIZE);
> if (!blocksize) {
> - ext4_msg(sb, KERN_ERR, "unable to set blocksize");
> + ext4_msg(sb, KERN_ERR,
> + "unable to set filesystem block size "
> + __stringify(EXT4_MIN_BL
[PATCH] staging: rtl8712: consolidate kmalloc/memset 0 of array to kcalloc
This is an API consolidation only. The use of kmalloc of an array of elements of equal size + memset to 0 of the same is equivalent to kcalloc. Signed-off-by: Nicholas Mc Guire --- Found by coccinelle script (relaxed version of scripts/coccinelle/api/alloc/kzalloc-simple.cocci) Patch was compile tested with: x86_64_defconfig + CONFIG_STAGING=y, CONFIG_R8712U=m Patch is against linux-next (localversion-next is -next-20160104) drivers/staging/rtl8712/rtl871x_recv.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/drivers/staging/rtl8712/rtl871x_recv.c b/drivers/staging/rtl8712/rtl871x_recv.c index 4ff5301..aa841bf 100644 --- a/drivers/staging/rtl8712/rtl871x_recv.c +++ b/drivers/staging/rtl8712/rtl871x_recv.c @@ -72,14 +72,12 @@ sint _r8712_init_recv_priv(struct recv_priv *precvpriv, _init_queue(&precvpriv->recv_pending_queue); precvpriv->adapter = padapter; precvpriv->free_recvframe_cnt = NR_RECVFRAME; - precvpriv->pallocated_frame_buf = kmalloc(NR_RECVFRAME * + precvpriv->pallocated_frame_buf = kcalloc(NR_RECVFRAME, sizeof(union recv_frame) + RXFRAME_ALIGN_SZ, GFP_ATOMIC); if (precvpriv->pallocated_frame_buf == NULL) return _FAIL; kmemleak_not_leak(precvpriv->pallocated_frame_buf); - memset(precvpriv->pallocated_frame_buf, 0, NR_RECVFRAME * - sizeof(union recv_frame) + RXFRAME_ALIGN_SZ); precvpriv->precv_frame_buf = precvpriv->pallocated_frame_buf + RXFRAME_ALIGN_SZ - ((addr_t)(precvpriv->pallocated_frame_buf) & -- 2.1.4 -- 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: Fix potential NULL pointer dereference in __skb_try_recv_datagram
On Wed, Dec 30, 2015 at 11:30 PM, Cong Wang wrote: > On Wed, Dec 30, 2015 at 6:30 AM, Jacob Siverskog > wrote: >> On Wed, Dec 30, 2015 at 2:26 PM, Eric Dumazet wrote: >>> How often can you trigger this bug ? >> >> Ok. I don't have a good repro to trigger it unfortunately, I've seen it just >> a >> few times when bringing up/down network interfaces. Does the trace >> give any clue? >> > > A little bit. You need to help people to narrow down the problem > because there are too many places using skb->next and skb->prev. > > Since you mentioned it seems related to network interface flip, > what network interfaces are you using? What's is your TC setup? > > Thanks. The system contains only one physical network interface (TI WL1837, wl18xx module). The state prior to the crash was as follows: - One virtual network interface active (as STA, associated with access point) - Bluetooth (BLE only) active (same physical chip, co-existence, btwilink/st_drv modules) Actions made around the time of the crash: - Bluetooth disabled - One additional virtual network interface brought up (also as STA) I believe the crash occurred between these two actions. I just saw that there are some interesting events in the log prior to the crash: kernel: Bluetooth: Unable to push skb to HCI core(-6) kernel: (stc): proto stack 4's ->recv failed kernel: (stc): remove_channel_from_table: id 3 kernel: (stc): remove_channel_from_table: id 2 kernel: (stc): remove_channel_from_table: id 4 kernel: (stc): all chnl_ids unregistered kernel: (stk) :ldisc_install = 0(stc): st_tty_close The first print is from btwilink.c. However, I can't see the connection between Bluetooth (BLE) and UDP/IPv6 (we're not using 6LoWPAN or anything similar). Thanks, Jacob -- 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: [RESEND PATCH] rtc: rk808: rename rtc-rk808.c to rtc-rk8xx.c
Hi Zhang Qing,
On 12/31/2015 10:14 PM, zhangqing wrote:
make rtc-rk8xx.c compatible for all pmic chips.
for pmic chips(rk808\rk807\rk816\rk818) in the future.
The commit message will be better like this:
Rename the file to rtc-rk8xx.c to compatible other Rockchip PMIC chips
like rk807/rk816/rk818 and other chips in the the future.
Also rename the variable, MACRO, function and etc. names in relate file.
Signed-off-by: zhangqing
Prefer to use: Zhang Qing
---
drivers/mfd/rk808.c | 2 +-
drivers/rtc/Kconfig | 8 +-
drivers/rtc/Makefile | 2 +-
drivers/rtc/{rtc-rk808.c => rtc-rk8xx.c} | 218 ++-
4 files changed, 131 insertions(+), 99 deletions(-)
rename drivers/rtc/{rtc-rk808.c => rtc-rk8xx.c} (64%)
diff --git a/drivers/mfd/rk808.c b/drivers/mfd/rk808.c
index 4b1e439..21da22b 100644
--- a/drivers/mfd/rk808.c
+++ b/drivers/mfd/rk808.c
@@ -77,7 +77,7 @@ static const struct mfd_cell rk808s[] = {
{ .name = "rk808-clkout", },
{ .name = "rk808-regulator", },
{
- .name = "rk808-rtc",
+ .name = "rk8xx-rtc",
.num_resources = ARRAY_SIZE(rtc_resources),
.resources = &rtc_resources[0],
},
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 376322f..d669473d 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -325,15 +325,15 @@ config RTC_DRV_MAX77686
This driver can also be built as a module. If so, the module
will be called rtc-max77686.
-config RTC_DRV_RK808
- tristate "Rockchip RK808 RTC"
+config RTC_DRV_RK8XX
+ tristate "Rockchip RK8XX RTC"
depends on MFD_RK808
help
If you say yes here you will get support for the
- RTC of RK808 PMIC.
+ RTC of RK8XX PMIC.
This driver can also be built as a module. If so, the module
- will be called rk808-rtc.
+ will be called rk8xx-rtc.
config RTC_DRV_MAX77802
tristate "Maxim 77802 RTC"
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 62d61b2..5b1384a 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -120,7 +120,7 @@ obj-$(CONFIG_RTC_DRV_PUV3) += rtc-puv3.o
obj-$(CONFIG_RTC_DRV_PXA) += rtc-pxa.o
obj-$(CONFIG_RTC_DRV_R9701) += rtc-r9701.o
obj-$(CONFIG_RTC_DRV_RC5T583) += rtc-rc5t583.o
-obj-$(CONFIG_RTC_DRV_RK808)+= rtc-rk808.o
+obj-$(CONFIG_RTC_DRV_RK8XX)+= rtc-rk8xx.o
obj-$(CONFIG_RTC_DRV_RP5C01) += rtc-rp5c01.o
obj-$(CONFIG_RTC_DRV_RS5C313) += rtc-rs5c313.o
obj-$(CONFIG_RTC_DRV_RS5C348) += rtc-rs5c348.o
diff --git a/drivers/rtc/rtc-rk808.c b/drivers/rtc/rtc-rk8xx.c
similarity index 64%
rename from drivers/rtc/rtc-rk808.c
rename to drivers/rtc/rtc-rk8xx.c
index 35c9aad..5d946bf 100644
--- a/drivers/rtc/rtc-rk808.c
+++ b/drivers/rtc/rtc-rk8xx.c
@@ -1,5 +1,5 @@
/*
- * RTC driver for Rockchip RK808
+ * RTC driver for Rockchip RK8XX
*
* Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
*
@@ -20,14 +20,33 @@
#include
#include
#include
-#include
#include
#include
+#include
+
+#define RK8XX_SECONDS_REG 0x00
+#define RK8XX_MINUTES_REG 0x01
+#define RK8XX_HOURS_REG0x02
+#define RK8XX_DAYS_REG 0x03
+#define RK8XX_MONTHS_REG 0x04
+#define RK8XX_YEARS_REG0x05
+#define RK8XX_WEEKS_REG0x06
+#define RK8XX_ALARM_SECONDS_REG0x08
+#define RK8XX_ALARM_MINUTES_REG0x09
+#define RK8XX_ALARM_HOURS_REG 0x0A
+#define RK8XX_ALARM_DAYS_REG 0x0B
+#define RK8XX_ALARM_MONTHS_REG 0x0C
+#define RK8XX_ALARM_YEARS_REG 0x0D
+#define RK8XX_RTC_CTRL_REG 0x10
+#define RK8XX_RTC_STATUS_REG 0x11
+#define RK8XX_RTC_INT_REG 0x12
+#define RK8XX_RTC_COMP_LSB_REG 0x13
+#define RK8XX_RTC_COMP_MSB_REG 0x14
/* RTC_CTRL_REG bitfields */
#define BIT_RTC_CTRL_REG_STOP_RTC_M BIT(0)
-/* RK808 has a shadowed register for saving a "frozen" RTC time.
+/* RK8xx has a shadowed register for saving a "frozen" RTC time.
* When user setting "GET_TIME" to 1, the time will save in this shadowed
* register. If set "READSEL" to 1, user read rtc time register, actually
* get the time of that moment. If we need the real time, clr this bit.
@@ -47,17 +66,25 @@
/* REG_SECONDS_REG through REG_YEARS_REG is how many registers? */
-#define NUM_TIME_REGS (RK808_WEEKS_REG - RK808_SECONDS_REG + 1)
-#define NUM_ALARM_REGS (RK808_ALARM_YEARS_REG - RK808_ALARM_SECONDS_REG + 1)
+#define NUM_TIME_REGS (RK8XX_WEEKS_REG - RK8XX_SECONDS_REG + 1)
+#define NUM_ALARM_REGS (RK8XX_ALARM_YEARS_REG - RK8XX_ALARM_SECONDS_REG
[PATCH v3 0/2] cpufreq: powernv: Redesign the presentation of throttle notification
In POWER8, OCC(On-Chip-Controller) can throttle the frequency of the CPU when the chip crosses its thermal and power limits. Currently, powernv-cpufreq driver detects and reports this event as a console message. Some boxes may not sustain the max turbo frequency in all conditions and can be throttled frequently. This can lead to the flooding of console with throttle messages. So this patchset aims to redesign the presentation of this event via sysfs counters and tracepoints. This patchset will add a perf trace point "power:powernv_throttle" and sysfs throttle counter stats in /sys/devices/system/cpu/cpufreq/chipN. Changes from v2: - Fixed kbuild test warning. drivers/cpufreq/powernv-cpufreq.c:609:2: warning: ignoring return value of 'kstrtoint', declared with attribute warn_unused_result [-Wunused-result] Shilpasri G Bhat (2): cpufreq: powernv/tracing: Add powernv_throttle tracepoint cpufreq: powernv: Redesign the presentation of throttle notification drivers/cpufreq/powernv-cpufreq.c | 256 +++--- include/trace/events/power.h | 22 kernel/trace/power-traces.c | 1 + 3 files changed, 236 insertions(+), 43 deletions(-) -- 1.9.3 -- 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 net-next] net: ethernet: cadence-macb: Add disabled usrio caps
Le 04/01/2016 10:01, Neil Armstrong a écrit :
> On some platforms, the macb integration does not use the USRIO
> register to configure the (R)MII port and clocks.
> When the register is not implemented and the MACB error signal
> is connected to the bus error, reading or writing to the USRIO
> register can trigger some Imprecise External Aborts on ARM platforms.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/net/ethernet/cadence/macb.c | 27 +++
> drivers/net/ethernet/cadence/macb.h | 1 +
> 2 files changed, 16 insertions(+), 12 deletions(-)
>
> Nicolas,
> I post only the first patch of the previous set posted here :
> http://lkml.kernel.org/r/1449582726-6148-1-git-send-email-narmstr...@baylibre.com
> to hopefully make it into the 4.5 merge time,
> I'll post the vendor prefix once this patch will hit mainline.
Okay, but I don't see how you will activate this capability (or I lost
track of it). So, before I can accept one solution, can you please
repost the whole solution as a v4.
Thanks. Bye,
>
> Regards,
> Neil
>
> diff --git a/drivers/net/ethernet/cadence/macb.c
> b/drivers/net/ethernet/cadence/macb.c
> index 8b45bc9..fa53bc3 100644
> --- a/drivers/net/ethernet/cadence/macb.c
> +++ b/drivers/net/ethernet/cadence/macb.c
> @@ -2124,7 +2124,8 @@ static void macb_get_regs(struct net_device *dev,
> struct ethtool_regs *regs,
> regs_buff[10] = macb_tx_dma(&bp->queues[0], tail);
> regs_buff[11] = macb_tx_dma(&bp->queues[0], head);
>
> - regs_buff[12] = macb_or_gem_readl(bp, USRIO);
> + if (!(bp->caps & MACB_CAPS_USRIO_DISABLED))
> + regs_buff[12] = macb_or_gem_readl(bp, USRIO);
> if (macb_is_gem(bp)) {
> regs_buff[13] = gem_readl(bp, DMACFG);
> }
> @@ -2403,19 +2404,21 @@ static int macb_init(struct platform_device *pdev)
> dev->hw_features &= ~NETIF_F_SG;
> dev->features = dev->hw_features;
>
> - val = 0;
> - if (bp->phy_interface == PHY_INTERFACE_MODE_RGMII)
> - val = GEM_BIT(RGMII);
> - else if (bp->phy_interface == PHY_INTERFACE_MODE_RMII &&
> - (bp->caps & MACB_CAPS_USRIO_DEFAULT_IS_MII))
> - val = MACB_BIT(RMII);
> - else if (!(bp->caps & MACB_CAPS_USRIO_DEFAULT_IS_MII))
> - val = MACB_BIT(MII);
> + if (!(bp->caps & MACB_CAPS_USRIO_DISABLED)) {
> + val = 0;
> + if (bp->phy_interface == PHY_INTERFACE_MODE_RGMII)
> + val = GEM_BIT(RGMII);
> + else if (bp->phy_interface == PHY_INTERFACE_MODE_RMII &&
> + (bp->caps & MACB_CAPS_USRIO_DEFAULT_IS_MII))
> + val = MACB_BIT(RMII);
> + else if (!(bp->caps & MACB_CAPS_USRIO_DEFAULT_IS_MII))
> + val = MACB_BIT(MII);
>
> - if (bp->caps & MACB_CAPS_USRIO_HAS_CLKEN)
> - val |= MACB_BIT(CLKEN);
> + if (bp->caps & MACB_CAPS_USRIO_HAS_CLKEN)
> + val |= MACB_BIT(CLKEN);
>
> - macb_or_gem_writel(bp, USRIO, val);
> + macb_or_gem_writel(bp, USRIO, val);
> + }
>
> /* Set MII management clock divider */
> val = macb_mdc_clk_div(bp);
> diff --git a/drivers/net/ethernet/cadence/macb.h
> b/drivers/net/ethernet/cadence/macb.h
> index 5c03e81..0d4ecfc 100644
> --- a/drivers/net/ethernet/cadence/macb.h
> +++ b/drivers/net/ethernet/cadence/macb.h
> @@ -400,6 +400,7 @@
> #define MACB_CAPS_USRIO_HAS_CLKEN0x0002
> #define MACB_CAPS_USRIO_DEFAULT_IS_MII 0x0004
> #define MACB_CAPS_NO_GIGABIT_HALF0x0008
> +#define MACB_CAPS_USRIO_DISABLED 0x0010
> #define MACB_CAPS_FIFO_MODE 0x1000
> #define MACB_CAPS_GIGABIT_MODE_AVAILABLE 0x2000
> #define MACB_CAPS_SG_DISABLED0x4000
>
--
Nicolas Ferre
--
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 v3 2/2] cpufreq: powernv: Redesign the presentation of throttle notification
Replace the throttling event console messages to perf trace point
"power:powernv_throttle" and throttle counter stats which are
exported in sysfs in /sys/devices/system/cpu/cpufreq/chipN. The
newly added sysfs files are as follows:
1)/sys/devices/system/cpu/cpufreq/chip0/throttle_frequencies
This gives the throttle stats for each of the available frequencies.
The throttle stat of a frequency is the total number of times the max
frequency is reduced to that frequency.
# cat /sys/devices/system/cpu/cpufreq/chip0/throttle_frequencies
4023000 0
399 0
3956000 1
3923000 0
389 0
3857000 2
3823000 0
379 0
3757000 2
3724000 1
369 1
...
2)/sys/devices/system/cpu/cpufreq/chip0/throttle_reasons
This directory contains throttle reason files. Each file gives the
total number of times the max frequency is throttled, except for
'throttle_reset', which gives the total number of times the max
frequency is unthrottled after being throttled.
# cd /sys/devices/system/cpu/cpufreq/chip0/throttle_reasons
# cat cpu_over_temperature
7
# cat occ_reset
0
# cat over_current
0
# cat power_cap
0
# cat power_supply_failure
0
# cat throttle_reset
7
3)/sys/devices/system/cpu/cpufreq/chip0/throttle_stat
This gives the total number of events of max frequency throttling to
lower frequencies in the turbo range of frequencies and the sub-turbo(at
and below nominal) range of frequencies.
# cat /sys/devices/system/cpu/cpufreq/chip0/throttle_stat
turbo 7
sub-turbo 0
Signed-off-by: Shilpasri G Bhat
---
Changes from v2:
- Fixed kbuild test warning.
drivers/cpufreq/powernv-cpufreq.c:609:2: warning: ignoring return
value of 'kstrtoint', declared with attribute warn_unused_result
[-Wunused-result]
Changes from v1:
- Added a kobject to struct chip
- Grouped the throttle reasons under a separate attribute_group and
exported each reason as individual file.
- Moved the sysfs files from /sys/devices/system/node/nodeN to
/sys/devices/system/cpu/cpufreq/chipN
- As suggested by Paul Clarke replaced 'Nominal' with 'sub-turbo' and
char * throttle_reason[][30] by const char * const throttle_reason[].
- Modified the commit message.
drivers/cpufreq/powernv-cpufreq.c | 256 +++---
1 file changed, 213 insertions(+), 43 deletions(-)
diff --git a/drivers/cpufreq/powernv-cpufreq.c
b/drivers/cpufreq/powernv-cpufreq.c
index cb50138..5574f06 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -43,12 +44,37 @@
static struct cpufreq_frequency_table powernv_freqs[POWERNV_MAX_PSTATES+1];
static bool rebooting, throttled, occ_reset;
+static const char * const throttle_reason[] = {
+ "No throttling",
+ "Power Cap",
+ "Processor Over Temperature",
+ "Power Supply Failure",
+ "Over Current",
+ "OCC Reset"
+};
+
+enum throt_reason_type {
+ NO_THROTTLE = 0,
+ POWERCAP,
+ CPU_OVERTEMP,
+ POWER_SUPPLY_FAILURE,
+ OVERCURRENT,
+ OCC_RESET_THROTTLE
+};
+
static struct chip {
unsigned int id;
bool throttled;
cpumask_t mask;
struct work_struct throttle;
bool restore;
+ /* Pmax throttle stats */
+ int throt_reason;
+ int throt_turbo;
+ int throt_nominal;
+ int reason[OCC_MAX_THROTTLE_STATUS + 1];
+ int *pstate_stat;
+ struct kobject *kobj;
} *chips;
static int nr_chips;
@@ -309,11 +335,11 @@ static inline unsigned int get_nominal_index(void)
return powernv_pstate_info.max - powernv_pstate_info.nominal;
}
-static void powernv_cpufreq_throttle_check(void *data)
+static void powernv_cpufreq_read_pmax(void *data)
{
unsigned int cpu = smp_processor_id();
unsigned long pmsr;
- int pmsr_pmax, i;
+ int pmsr_pmax, i, index;
pmsr = get_pmspr(SPRN_PMSR);
@@ -321,28 +347,43 @@ static void powernv_cpufreq_throttle_check(void *data)
if (chips[i].id == cpu_to_chip_id(cpu))
break;
- /* Check for Pmax Capping */
pmsr_pmax = (s8)PMSR_MAX(pmsr);
if (pmsr_pmax != powernv_pstate_info.max) {
if (chips[i].throttled)
- goto next;
+ return;
chips[i].throttled = true;
- if (pmsr_pmax < powernv_pstate_info.nominal)
- pr_crit("CPU %d on Chip %u has Pmax reduced below
nominal frequency (%d < %d)\n",
- cpu, chips[i].id, pmsr_pmax,
+ if (pmsr_pmax < powernv_pstate_info.nominal) {
+ pr_warn_once("CPU %d on Chip %u has Pmax reduced below
nominal frequency (%d < %d)\n",
+cpu, chips[i].id, pmsr_pmax,
powernv_pstate_info.nominal);
- e
[PATCH v3 1/2] cpufreq: powernv/tracing: Add powernv_throttle tracepoint
This patch adds the powernv_throttle tracepoint to trace the CPU
frequency throttling event, which is used by the powernv-cpufreq
driver in POWER8.
Signed-off-by: Shilpasri G Bhat
CC: Ingo Molnar
CC: Steven Rostedt
---
No changes from v2.
Changes from v1:
- Export the tracepoint
include/trace/events/power.h | 22 ++
kernel/trace/power-traces.c | 1 +
2 files changed, 23 insertions(+)
diff --git a/include/trace/events/power.h b/include/trace/events/power.h
index 284244e..19e5030 100644
--- a/include/trace/events/power.h
+++ b/include/trace/events/power.h
@@ -38,6 +38,28 @@ DEFINE_EVENT(cpu, cpu_idle,
TP_ARGS(state, cpu_id)
);
+TRACE_EVENT(powernv_throttle,
+
+ TP_PROTO(int chip_id, const char *reason, int pmax),
+
+ TP_ARGS(chip_id, reason, pmax),
+
+ TP_STRUCT__entry(
+ __field(int, chip_id)
+ __string(reason, reason)
+ __field(int, pmax)
+ ),
+
+ TP_fast_assign(
+ __entry->chip_id = chip_id;
+ __assign_str(reason, reason);
+ __entry->pmax = pmax;
+ ),
+
+ TP_printk("Chip %d Pmax %d %s", __entry->chip_id,
+ __entry->pmax, __get_str(reason))
+);
+
TRACE_EVENT(pstate_sample,
TP_PROTO(u32 core_busy,
diff --git a/kernel/trace/power-traces.c b/kernel/trace/power-traces.c
index eb4220a..81b8745 100644
--- a/kernel/trace/power-traces.c
+++ b/kernel/trace/power-traces.c
@@ -15,4 +15,5 @@
EXPORT_TRACEPOINT_SYMBOL_GPL(suspend_resume);
EXPORT_TRACEPOINT_SYMBOL_GPL(cpu_idle);
+EXPORT_TRACEPOINT_SYMBOL_GPL(powernv_throttle);
--
1.9.3
--
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 14/16] x86,nvdimm,kexec: Use walk_iomem_res_desc() for iomem search
Hi, Toshi,
On 12/25/15 at 03:09pm, Toshi Kani wrote:
> Change to call walk_iomem_res_desc() for searching resource entries
> with the following names:
> "ACPI Tables"
> "ACPI Non-volatile Storage"
> "Persistent Memory (legacy)"
> "Crash kernel"
>
> Note, the caller of walk_iomem_res() with "GART" is left unchanged
> because this entry may be initialized by out-of-tree drivers, which
> do not have 'desc' set to IORES_DESC_GART.
Found below commit which initialize the GART entry:
commit 56dd669a138c40ea6cdae487f233430d12372767
Author: Aaron Durbin
Date: Tue Sep 26 10:52:40 2006 +0200
[PATCH] Insert GART region into resource map
Patch inserts the GART region into the iomem resource map. The GART will
then
be visible within /proc/iomem. It will also allow for other users
utilizing the GART to subreserve the region (agp or IOMMU).
Signed-off-by: Aaron Durbin
But later it was reverted:
commit 707d4eefbdb31f8e588277157056b0ce637d6c68
Author: Bjorn Helgaas
Date: Tue Mar 18 14:26:12 2014 -0600
Revert "[PATCH] Insert GART region into resource map"
This reverts commit 56dd669a138c, which makes the GART visible in
/proc/iomem. This fixes a regression: e501b3d87f00 ("agp: Support 64-bit
APBASE") exposed an existing problem with a conflict between the GART
region and a PCI BAR region.
The GART addresses are bus addresses, not CPU addresses, and therefore
should not be inserted in iomem_resource.
On many machines, the GART region is addressable by the CPU as well as by
an AGP master, but CPU addressability is not required by the spec. On some
of these machines, the GART is mapped by a PCI BAR, and in that case, the
PCI core automatically inserts it into iomem_resource, just as it does for
all BARs.
Inserting it here means we'll have a conflict if the PCI core later tries
to claim the GART region, so let's drop the insertion here.
The conflict indirectly causes X failures, as reported by Jouni in the
bugzilla below. We detected the conflict even before e501b3d87f00, but
after it the AGP code (fix_northbridge()) uses the PCI resource (which is
zeroed because of the conflict) instead of reading the BAR again.
Conflicts:
arch/x86_64/kernel/aperture.c
Fixes: e501b3d87f00 agp: Support 64-bit APBASE
Link: https://bugzilla.kernel.org/show_bug.cgi?id=72201
Reported-and-tested-by: Jouni Mettälä
Signed-off-by: Bjorn Helgaas
For amd64 agp, currently the region name is "aperture" instead:
drivers/char/agp/amd64-agp.c: agp_aperture_valid()
This may not be the only case, but I doubt that anyone is testing this since
long time ago kexec-tools excluding the 'GART' region. Kexec-tools and
kexec_file
may need update to use "aperture" if someone can test it.
I think adding an enum value for compatibility is reasonable, we do not care
about third party drivers in mainline.
Thanks
Dave
--
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/3] rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt()
These patches are labour intensive to review because you can't just do it in the email client. Also you were not able to review it properly yourself and introduced a bug. I am often remove initializers but it's normally because I am changing something else which makes it worthwhile. This patch is the correct thing but it's not "worthwhile". It is not a good use of my time. Please stop sending cleanup patches, Markus. Just send fixes. 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: [PATCH v2 14/16] x86, nvdimm, kexec: Use walk_iomem_res_desc() for iomem search
Hi, Boris On 12/27/15 at 11:24am, Borislav Petkov wrote: > On Sun, Dec 27, 2015 at 10:12:57AM +0800, Minfei Huang wrote: > > You can refer the below link that you may get a clue about GART. This is > > the fisrt time kexec-tools tried to support to ignore GART region in 2nd > > kernel. > > > > http://lists.infradead.org/pipermail/kexec/2008-December/003096.html > > So theoretically we could export that IORES_DESC* enum in an uapi header and > move kexec-tools to use that. > > However, I'm fuzzy on how exactly the whole compatibility thing is done > with kexec-tools and the kernel. We probably would have to support > newer kexec-tools on an older kernel and vice versa so I'd guess we > should mark walk_iomem_res() deprecated so that people are encouraged to > upgrade to newer kexec-tools... Replied to Toshi old kernel will export the "GART" region for amd cards. So for old kernel and new kexec-tools we will have problem. I think add the GART desc for compitibility purpose is doable, no? Thanks Dave -- 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/3] net-iwlegacy: Refactoring for il_eeprom_init()
On Fri, Jan 01, 2016 at 09:30:10PM +0100, SF Markus Elfring wrote: > From: Markus Elfring > Date: Fri, 1 Jan 2016 20:54:25 +0100 > > Return directly if a memory allocation failed at the beginning. > > Signed-off-by: Markus Elfring Acked-by: Stanislaw Gruszka -- 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 00/19] irqchip: atmel-aic: make unified AIC driver
Le 04/01/2016 10:02, Boris Brezillon a écrit : > Hi Milo, > > On Mon, 4 Jan 2016 13:28:24 +0900 > Milo Kim wrote: > >> This patch-set provides unified Atmel AIC (Advanced Interrupt Controller) >> driver. Currently, there are two AIC drivers, AIC and AIC5. >> Each driver consists of chip specific part (irq-atmel-aic.o or >> irq-atmel-aic5.o) and shared code (irq-atmel-aic-common.o). >> But consolidated AIC driver is just one file driver which supports both >> IRQ chip systems. > > Sorry, but what's the real motivation behind this rework? I was about to ask the same question. I'm really sorry that you spent so much time and effort for something that I'm absolutely against: reworking stable code that had been maturing for years and that is now nicely stable... for no obvious reason... So unless there is a very strong benefit, it's a pretty firm NACK for this series. We will certainly take some time to review the bits that can be taken further to enhance our current drivers. I also advice you to talk to us before starting such a big project and you'll notice that we are open to changes and have many aspect that you can work on with AT91. Bye, >> How to handle two IRQ chips in one driver >> - >> Structure aic_reg_offset is used for device configuration. >> AIC5 IRQ chip uses SSR (Source Select Register) to select IRQ number. >> On the other hand, AIC IRQ chip has simple register access. >> To support both IRQ chips, aic_is_ssr_used() helper is used. >> >> Patches >> --- >> 1 ~ 5: fix IRQ priority issue, clean up RTC/RTT fixup code and etc. > > As explained in my review, those irq fixup are essential, and cannot > remove them. > >> 6 ~ 19: create unified IRQ chip operation with aic_reg_offset data. > > I started to review those patches, but honestly I don't see the point of > this rework, since you're trying to merge drivers for 2 IPs that are > completely different from a functional POV (except for a few tiny things > like priority or irq type definition). > > Before reviewing the remaining patches, I'd like to know more about your > real motivations for pushing those changes? > >> >> Target boards >> - >> Tested with two boards. >> * Arietta G25 (SoC: AT91SAM9G25) >> * Xplained board (SoC: SAMA5D3) >> >> Number of driver files >> -- >> AIC: 3 (irq-atmel-aic.c, irq-atmel-aic-common.c and h) >> AIC5: 3 (irq-atmel-aic5.c, irq-atmel-aic-common.c and h) >> Consolidated AIC: 1 (irq-aic.c) >> >> Code size >> - >> AIC (irq-atmel-aic.o and irq-atmel-aic-common.o) >> textdata bss dec hex filename >> 5137 196 4533714d9 drivers/irqchip/built-in.o >> >> AIC5 (irq-atmel-aic5.o and irq-atmel-aic-common.o) >> textdata bss dec hex filename >> 5548 196 457481674 drivers/irqchip/built-in.o >> >> Consolidated AIC (irq-aic.o) >> textdata bss dec hex filename >> 4841 196 8504513b5 drivers/irqchip/built-in.o >> >> Lines of code >> - >> AIC: 597 >> AIC5: 688 >> Consolidated AIC: 609 > > > Please, redo the same thing, but after keeping the IRQ fixup stuff, and > I'm pretty sure the text section of the AIC/AIC5 and the consolidated > version will be much closer. > > Not to mention that you're adding a bunch of if () statements in the > critical IRQ path, which is never a good think for latency concern. > > Best Regards, > > Boris > >> >> Milo Kim (19): >> irqchip: atmel-aic: fix wrong bit operation for IRQ priority >> irqchip: atmel-aic: clean up RTC interrupt code >> irqchip: atmel-aic: clean up RTT interrupt code >> irqchip: atmel-aic: replace magic numbers with named constant >> irqchip: atmel-aic: use simple constant to get number of interrupts >> per chip >> irqchip: atmel-aic: introduce register data structure >> irqchip: atmel-aic: make common IRQ domain translate function >> irqchip: atmel-aic: add common mask and unmask functions >> irqchip: atmel-aic: add common retrigger function >> irqchip: atmel-aic: add common set_type function >> irqchip: atmel-aic: add common PM IRQ chip operation >> irqchip: atmel-aic: use EOI register data in aic_reg_data >> irqchip: atmel-aic: clean up irq_chip_generic >> irqchip: atmel-aic: add common HW init function >> irqchip: atmel-aic: add common interrupt handler >> irqchip: atmel-aic: get total number of IRQs from device node >> irqchip: atmel-aic: use unified IRQ chip initialization function >> irqchip: atmel-aic: use unified AIC driver >> irqchip: atmel-aic: rename AIC driver and fix Kconfig >> >> arch/arm/mach-at91/Kconfig | 2 +- >> drivers/irqchip/Kconfig| 7 - >> drivers/irqchip/Makefile | 3 +- >> drivers/irqchip/irq-aic.c | 609 >> ++
Re: [PATCH 1/3] rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt()
Btw, GCC misses a lot of uninitialized variable bugs. I have a Smatch check which sometimes catches the bugs that GCC misses but you should not rely on the tools here. These patches need to be reviewed manually. And the "goto err" before the initialization makes everything more complicated (that's actually what caused the bug in this patch, in fact). 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: [PATCH] iwlegacy: 4965-mac: constify il_sensitivity_ranges structure
On Wed, Dec 30, 2015 at 12:20:49PM +0100, Julia Lawall wrote: > The il_sensitivity_ranges is never modified, so declare it as const. > > Done with the help of Coccinelle. > > Signed-off-by: Julia Lawall Acked-by: Stanislaw Gruszka -- 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 0/5] xen-netback: Fine-tuning for three function implementations
The original code is fine. 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: [PATCH] s390: fix normalization bug in exception table sorting
On Fri, Jan 01, 2016 at 01:39:22PM +0100, Ard Biesheuvel wrote:
> The normalization pass in the sorting routine of the relative exception
> table serves two purposes:
> - it ensures that the address fields of the exception table entries are
> fully ordered, so that no ambiguities arise between entries with
> identical instruction offsets (i.e., when two instructions that are
> exactly 8 bytes apart each have an exception table entry associated with
> them)
> - it ensures that the offsets of both the instruction and the fixup fields
> of each entry are relative to their final location after sorting.
>
> Commit eb608fb366de ("s390/exceptions: switch to relative exception table
> entries") ported the relative exception table format from x86, but modified
> the sorting routine to only normalize the instruction offset field and not
> the fixup offset field. The result is that the fixup offset of each entry
> will be relative to the original location of the entry before sorting,
> likely leading to crashes when those entries are dereferenced.
Applied, thanks a lot!
I was wondering why this never was observed on s390 during the last three
years.
The kernel text extable entries will be sorted during build time and I
verified that for the majority of modules the extable entries are already
sorted. And even if they are not sorted there isn't any major shuffling.
So it looks like we were simply lucky...
--
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 net-next 0/3] Add new capability and macb DT variant
The first patch introduces a new capability bit to disable usage of the USRIO register on platform not implementing it thus avoiding some external imprecise aborts on ARM based platforms. The two last patchs adds a new macb variant compatible name using the capability, the NPx name is temporary and must be fixed when the first patch hits mainline. Only the first patch should be merged right now until the compatible name is fixed. v1: http://lkml.kernel.org/r/1449485914-12883-1-git-send-email-narmstr...@baylibre.com v2: http://lkml.kernel.org/r/1449582726-6148-1-git-send-email-narmstr...@baylibre.com v3: http://lkml.kernel.org/r/1451898103-21868-1-git-send-email-narmstr...@baylibre.com v4: as nicolas suggested, use a new macb config and a new product/vendor prefix Neil Armstrong (3): net: ethernet: cadence-macb: Add disabled usrio caps net: macb: Add NPx macb config using USRIO_DISABLED cap dt-bindings: net: macb: Add NPx macb variant Documentation/devicetree/bindings/net/macb.txt | 1 + drivers/net/ethernet/cadence/macb.c| 33 -- drivers/net/ethernet/cadence/macb.h| 1 + 3 files changed, 23 insertions(+), 12 deletions(-) -- 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 v4 net-next 2/3] net: macb: Add NPx macb config using USRIO_DISABLED cap
Declare a new SoC variant for NPx SoCs having USRIO_DISABLED as
capability bit.
Signed-off-by: Neil Armstrong
---
drivers/net/ethernet/cadence/macb.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/net/ethernet/cadence/macb.c
b/drivers/net/ethernet/cadence/macb.c
index fa53bc3..a9e27a7 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -2781,6 +2781,11 @@ static const struct macb_config emac_config = {
.init = at91ether_init,
};
+static const struct macb_config npx_config = {
+ .caps = MACB_CAPS_USRIO_DISABLED,
+ .clk_init = macb_clk_init,
+ .init = macb_init,
+};
static const struct macb_config zynqmp_config = {
.caps = MACB_CAPS_GIGABIT_MODE_AVAILABLE | MACB_CAPS_JUMBO,
@@ -2801,6 +2806,7 @@ static const struct of_device_id macb_dt_ids[] = {
{ .compatible = "cdns,at32ap7000-macb" },
{ .compatible = "cdns,at91sam9260-macb", .data = &at91sam9260_config },
{ .compatible = "cdns,macb" },
+ { .compatible = "cdns,npx-macb", .data = &npx_config },
{ .compatible = "cdns,pc302-gem", .data = &pc302gem_config },
{ .compatible = "cdns,gem", .data = &pc302gem_config },
{ .compatible = "atmel,sama5d2-gem", .data = &sama5d2_config },
--
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 v4 net-next 3/3] dt-bindings: net: macb: Add NPx macb variant
Add NPx macb variant for NPx SoCs.
Signed-off-by: Neil Armstrong
---
Documentation/devicetree/bindings/net/macb.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/net/macb.txt
b/Documentation/devicetree/bindings/net/macb.txt
index 38c8e84..638cdde 100644
--- a/Documentation/devicetree/bindings/net/macb.txt
+++ b/Documentation/devicetree/bindings/net/macb.txt
@@ -4,6 +4,7 @@ Required properties:
- compatible: Should be "cdns,[-]{macb|gem}"
Use "cdns,at91sam9260-macb" for Atmel at91sam9 SoCs or the 10/100Mbit IP
available on sama5d3 SoCs.
+ Use "cdns,npx-macb" for NPX SoCs devices.
Use "cdns,at32ap7000-macb" for other 10/100 usage or use the generic form:
"cdns,macb".
Use "cdns,pc302-gem" for Picochip picoXcell pc302 and later devices based on
the Cadence GEM, or the generic form: "cdns,gem".
--
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 v4 net-next 1/3] net: ethernet: cadence-macb: Add disabled usrio caps
On some platforms, the macb integration does not use the USRIO
register to configure the (R)MII port and clocks.
When the register is not implemented and the MACB error signal
is connected to the bus error, reading or writing to the USRIO
register can trigger some Imprecise External Aborts on ARM platforms.
Signed-off-by: Neil Armstrong
---
drivers/net/ethernet/cadence/macb.c | 27 +++
drivers/net/ethernet/cadence/macb.h | 1 +
2 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.c
b/drivers/net/ethernet/cadence/macb.c
index 8b45bc9..fa53bc3 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -2124,7 +2124,8 @@ static void macb_get_regs(struct net_device *dev, struct
ethtool_regs *regs,
regs_buff[10] = macb_tx_dma(&bp->queues[0], tail);
regs_buff[11] = macb_tx_dma(&bp->queues[0], head);
- regs_buff[12] = macb_or_gem_readl(bp, USRIO);
+ if (!(bp->caps & MACB_CAPS_USRIO_DISABLED))
+ regs_buff[12] = macb_or_gem_readl(bp, USRIO);
if (macb_is_gem(bp)) {
regs_buff[13] = gem_readl(bp, DMACFG);
}
@@ -2403,19 +2404,21 @@ static int macb_init(struct platform_device *pdev)
dev->hw_features &= ~NETIF_F_SG;
dev->features = dev->hw_features;
- val = 0;
- if (bp->phy_interface == PHY_INTERFACE_MODE_RGMII)
- val = GEM_BIT(RGMII);
- else if (bp->phy_interface == PHY_INTERFACE_MODE_RMII &&
-(bp->caps & MACB_CAPS_USRIO_DEFAULT_IS_MII))
- val = MACB_BIT(RMII);
- else if (!(bp->caps & MACB_CAPS_USRIO_DEFAULT_IS_MII))
- val = MACB_BIT(MII);
+ if (!(bp->caps & MACB_CAPS_USRIO_DISABLED)) {
+ val = 0;
+ if (bp->phy_interface == PHY_INTERFACE_MODE_RGMII)
+ val = GEM_BIT(RGMII);
+ else if (bp->phy_interface == PHY_INTERFACE_MODE_RMII &&
+(bp->caps & MACB_CAPS_USRIO_DEFAULT_IS_MII))
+ val = MACB_BIT(RMII);
+ else if (!(bp->caps & MACB_CAPS_USRIO_DEFAULT_IS_MII))
+ val = MACB_BIT(MII);
- if (bp->caps & MACB_CAPS_USRIO_HAS_CLKEN)
- val |= MACB_BIT(CLKEN);
+ if (bp->caps & MACB_CAPS_USRIO_HAS_CLKEN)
+ val |= MACB_BIT(CLKEN);
- macb_or_gem_writel(bp, USRIO, val);
+ macb_or_gem_writel(bp, USRIO, val);
+ }
/* Set MII management clock divider */
val = macb_mdc_clk_div(bp);
diff --git a/drivers/net/ethernet/cadence/macb.h
b/drivers/net/ethernet/cadence/macb.h
index 5c03e81..0d4ecfc 100644
--- a/drivers/net/ethernet/cadence/macb.h
+++ b/drivers/net/ethernet/cadence/macb.h
@@ -400,6 +400,7 @@
#define MACB_CAPS_USRIO_HAS_CLKEN 0x0002
#define MACB_CAPS_USRIO_DEFAULT_IS_MII 0x0004
#define MACB_CAPS_NO_GIGABIT_HALF 0x0008
+#define MACB_CAPS_USRIO_DISABLED 0x0010
#define MACB_CAPS_FIFO_MODE0x1000
#define MACB_CAPS_GIGABIT_MODE_AVAILABLE 0x2000
#define MACB_CAPS_SG_DISABLED 0x4000
--
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] s390: fix normalization bug in exception table sorting
On 4 January 2016 at 10:42, Heiko Carstens wrote:
> On Fri, Jan 01, 2016 at 01:39:22PM +0100, Ard Biesheuvel wrote:
>> The normalization pass in the sorting routine of the relative exception
>> table serves two purposes:
>> - it ensures that the address fields of the exception table entries are
>> fully ordered, so that no ambiguities arise between entries with
>> identical instruction offsets (i.e., when two instructions that are
>> exactly 8 bytes apart each have an exception table entry associated with
>> them)
>> - it ensures that the offsets of both the instruction and the fixup fields
>> of each entry are relative to their final location after sorting.
>>
>> Commit eb608fb366de ("s390/exceptions: switch to relative exception table
>> entries") ported the relative exception table format from x86, but modified
>> the sorting routine to only normalize the instruction offset field and not
>> the fixup offset field. The result is that the fixup offset of each entry
>> will be relative to the original location of the entry before sorting,
>> likely leading to crashes when those entries are dereferenced.
>
> Applied, thanks a lot!
>
> I was wondering why this never was observed on s390 during the last three
> years.
>
> The kernel text extable entries will be sorted during build time and I
> verified that for the majority of modules the extable entries are already
> sorted. And even if they are not sorted there isn't any major shuffling.
> So it looks like we were simply lucky...
>
Indeed. I guess most modules only have a single .text section so the
entries are emitted in order.
--
Ard.
--
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: [RESEND PATCH] rtc: rk808: rename rtc-rk808.c to rtc-rk8xx.c
Hi,
On 31/12/2015 at 06:14:55 -0800, zhangqing wrote :
> make rtc-rk8xx.c compatible for all pmic chips.
> for pmic chips(rk808\rk807\rk816\rk818) in the future.
>
I'm not sure it is useful to do that renaming. It is usual to have one
driver that supports multiple chips named with the forst chip it
supported.
Also, what would happen if for example rk855 is not compatible at all
with the previous implementations?
> Signed-off-by: zhangqing
> ---
> drivers/mfd/rk808.c | 2 +-
> drivers/rtc/Kconfig | 8 +-
> drivers/rtc/Makefile | 2 +-
> drivers/rtc/{rtc-rk808.c => rtc-rk8xx.c} | 218
> ++-
> 4 files changed, 131 insertions(+), 99 deletions(-)
> rename drivers/rtc/{rtc-rk808.c => rtc-rk8xx.c} (64%)
>
> diff --git a/drivers/mfd/rk808.c b/drivers/mfd/rk808.c
> index 4b1e439..21da22b 100644
> --- a/drivers/mfd/rk808.c
> +++ b/drivers/mfd/rk808.c
> @@ -77,7 +77,7 @@ static const struct mfd_cell rk808s[] = {
> { .name = "rk808-clkout", },
> { .name = "rk808-regulator", },
> {
> - .name = "rk808-rtc",
> + .name = "rk8xx-rtc",
> .num_resources = ARRAY_SIZE(rtc_resources),
> .resources = &rtc_resources[0],
> },
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index 376322f..d669473d 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -325,15 +325,15 @@ config RTC_DRV_MAX77686
> This driver can also be built as a module. If so, the module
> will be called rtc-max77686.
>
> -config RTC_DRV_RK808
> - tristate "Rockchip RK808 RTC"
> +config RTC_DRV_RK8XX
> + tristate "Rockchip RK8XX RTC"
> depends on MFD_RK808
> help
> If you say yes here you will get support for the
> - RTC of RK808 PMIC.
> + RTC of RK8XX PMIC.
>
> This driver can also be built as a module. If so, the module
> - will be called rk808-rtc.
> + will be called rk8xx-rtc.
>
> config RTC_DRV_MAX77802
> tristate "Maxim 77802 RTC"
> diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
> index 62d61b2..5b1384a 100644
> --- a/drivers/rtc/Makefile
> +++ b/drivers/rtc/Makefile
> @@ -120,7 +120,7 @@ obj-$(CONFIG_RTC_DRV_PUV3)+= rtc-puv3.o
> obj-$(CONFIG_RTC_DRV_PXA)+= rtc-pxa.o
> obj-$(CONFIG_RTC_DRV_R9701) += rtc-r9701.o
> obj-$(CONFIG_RTC_DRV_RC5T583)+= rtc-rc5t583.o
> -obj-$(CONFIG_RTC_DRV_RK808) += rtc-rk808.o
> +obj-$(CONFIG_RTC_DRV_RK8XX) += rtc-rk8xx.o
> obj-$(CONFIG_RTC_DRV_RP5C01) += rtc-rp5c01.o
> obj-$(CONFIG_RTC_DRV_RS5C313)+= rtc-rs5c313.o
> obj-$(CONFIG_RTC_DRV_RS5C348)+= rtc-rs5c348.o
> diff --git a/drivers/rtc/rtc-rk808.c b/drivers/rtc/rtc-rk8xx.c
> similarity index 64%
> rename from drivers/rtc/rtc-rk808.c
> rename to drivers/rtc/rtc-rk8xx.c
> index 35c9aad..5d946bf 100644
> --- a/drivers/rtc/rtc-rk808.c
> +++ b/drivers/rtc/rtc-rk8xx.c
> @@ -1,5 +1,5 @@
> /*
> - * RTC driver for Rockchip RK808
> + * RTC driver for Rockchip RK8XX
> *
> * Copyright (c) 2014, Fuzhou Rockchip Electronics Co., Ltd
> *
> @@ -20,14 +20,33 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> +#include
> +
> +#define RK8XX_SECONDS_REG0x00
> +#define RK8XX_MINUTES_REG0x01
> +#define RK8XX_HOURS_REG 0x02
> +#define RK8XX_DAYS_REG 0x03
> +#define RK8XX_MONTHS_REG 0x04
> +#define RK8XX_YEARS_REG 0x05
> +#define RK8XX_WEEKS_REG 0x06
> +#define RK8XX_ALARM_SECONDS_REG 0x08
> +#define RK8XX_ALARM_MINUTES_REG 0x09
> +#define RK8XX_ALARM_HOURS_REG0x0A
> +#define RK8XX_ALARM_DAYS_REG 0x0B
> +#define RK8XX_ALARM_MONTHS_REG 0x0C
> +#define RK8XX_ALARM_YEARS_REG0x0D
> +#define RK8XX_RTC_CTRL_REG 0x10
> +#define RK8XX_RTC_STATUS_REG 0x11
> +#define RK8XX_RTC_INT_REG0x12
> +#define RK8XX_RTC_COMP_LSB_REG 0x13
> +#define RK8XX_RTC_COMP_MSB_REG 0x14
>
> /* RTC_CTRL_REG bitfields */
> #define BIT_RTC_CTRL_REG_STOP_RTC_M BIT(0)
>
> -/* RK808 has a shadowed register for saving a "frozen" RTC time.
> +/* RK8xx has a shadowed register for saving a "frozen" RTC time.
> * When user setting "GET_TIME" to 1, the time will save in this shadowed
> * register. If set "READSEL" to 1, user read rtc time register, actually
> * get the time of that moment. If we need the real time, clr this bit.
> @@ -47,17 +66,25 @@
>
> /* REG_SECONDS_REG through REG_YEARS_REG is how many registers? */
>
> -#define NUM_TIME_REGS(RK808_WEEKS_REG - RK808_SECONDS_REG + 1)
> -#define NUM_ALARM_REGS (RK808_ALARM_YEA
[PATCH v2] perf/probe: Search both .eh_frame and .debug_frame sections for probe location
perf probe through debuginfo__find_probes() in util/probe-finder.c
checks for the functions' frame descriptions in either .eh_frame section
of an ELF or the .debug_frame. The check is based on whether either one
of these sections is present. Depending on distro, toolchain defaults,
architetcutre, build flags, etc., CFI might be found in either .eh_frame
and/or .debug_frame. Sometimes, it may happen that, .eh_frame, even if
present, may not be complete and may miss some descriptions. Therefore,
to be sure, to find the CFI covering an address we will always have to
investigate both if available.
For e.g., in powerpc, this may happen :
$ gcc -g bin.c -o bin
$ objdump --dwarf ./bin
<1><145>: Abbrev Number: 7 (DW_TAG_subprogram)
<146> DW_AT_external: 1
<146> DW_AT_name: (indirect string, offset: 0x9e): main
<14a> DW_AT_decl_file : 1
<14b> DW_AT_decl_line : 39
<14c> DW_AT_prototyped : 1
<14c> DW_AT_type: <0x57>
<150> DW_AT_low_pc : 0x17b8
If the .eh_frame and .debug_frame are checked for the same binary, we
will find that, .eh_frame (although present) doesn't contain a
description for "main" function.
But, .debug_frame has a description :
00d8 0024 FDE cie= pc=17b8..1838
DW_CFA_advance_loc: 16 to 17c8
DW_CFA_def_cfa_offset: 144
DW_CFA_offset_extended_sf: r65 at cfa+16
...
Due to this (since, perf checks whether .eh_frame is present and goes on
searching for that address inside that frame), perf is unable to process
the probes :
# perf probe -x ./bin main
Failed to get call frame on 0x17b8
Error: Failed to add events.
To avoid this issue, we need to check both the sections (.eh_frame and
.debug_frame), which is done in this patch.
Note that, we can always force everything into both .eh_frame and
.debug_frame by :
$ gcc bin.c -fasynchronous-unwind-tables -fno-dwarf2-cfi-asm -g -o bin
Signed-off-by: Hemant Kumar
---
Changes since v1:
- pf->cfi is now cached as pf->cfi_eh and pf->cfi_dbg depending on the source
of CFI
(Suggested by Mark Wielard).
tools/perf/util/probe-finder.c | 63 +-
tools/perf/util/probe-finder.h | 5 +++-
2 files changed, 42 insertions(+), 26 deletions(-)
diff --git a/tools/perf/util/probe-finder.c b/tools/perf/util/probe-finder.c
index 05012bb..71bf27e 100644
--- a/tools/perf/util/probe-finder.c
+++ b/tools/perf/util/probe-finder.c
@@ -685,9 +685,10 @@ static int call_probe_finder(Dwarf_Die *sc_die, struct
probe_finder *pf)
pf->fb_ops = NULL;
#if _ELFUTILS_PREREQ(0, 142)
} else if (nops == 1 && pf->fb_ops[0].atom == DW_OP_call_frame_cfa &&
- pf->cfi != NULL) {
+ (pf->cfi_eh != NULL || pf->cfi_dbg != NULL)) {
Dwarf_Frame *frame;
- if (dwarf_cfi_addrframe(pf->cfi, pf->addr, &frame) != 0 ||
+ if ((dwarf_cfi_addrframe(pf->cfi_eh, pf->addr, &frame) != 0 &&
+(dwarf_cfi_addrframe(pf->cfi_dbg, pf->addr, &frame) != 0))
||
dwarf_frame_cfa(frame, &pf->fb_ops, &nops) != 0) {
pr_warning("Failed to get call frame on 0x%jx\n",
(uintmax_t)pf->addr);
@@ -1013,8 +1014,7 @@ static int pubname_search_cb(Dwarf *dbg, Dwarf_Global
*gl, void *data)
return DWARF_CB_OK;
}
-/* Find probe points from debuginfo */
-static int debuginfo__find_probes(struct debuginfo *dbg,
+static int debuginfo__find_probe_location(struct debuginfo *dbg,
struct probe_finder *pf)
{
struct perf_probe_point *pp = &pf->pev->point;
@@ -1023,27 +1023,6 @@ static int debuginfo__find_probes(struct debuginfo *dbg,
Dwarf_Die *diep;
int ret = 0;
-#if _ELFUTILS_PREREQ(0, 142)
- Elf *elf;
- GElf_Ehdr ehdr;
- GElf_Shdr shdr;
-
- /* Get the call frame information from this dwarf */
- elf = dwarf_getelf(dbg->dbg);
- if (elf == NULL)
- return -EINVAL;
-
- if (gelf_getehdr(elf, &ehdr) == NULL)
- return -EINVAL;
-
- if (elf_section_by_name(elf, &ehdr, &shdr, ".eh_frame", NULL) &&
- shdr.sh_type == SHT_PROGBITS) {
- pf->cfi = dwarf_getcfi_elf(elf);
- } else {
- pf->cfi = dwarf_getcfi(dbg->dbg);
- }
-#endif
-
off = 0;
pf->lcache = intlist__new(NULL);
if (!pf->lcache)
@@ -1106,6 +1085,40 @@ found:
return ret;
}
+/* Find probe points from debuginfo */
+static int debuginfo__find_probes(struct debuginfo *dbg,
+ struct probe_finder *pf)
+{
+ int ret = 0;
+
+#if _ELFUTILS_PREREQ(0, 142)
+ Elf *elf;
+ GElf_Ehdr ehdr;
+ GElf_Shdr shdr;
+
+ if (pf->cfi_eh || pf->cfi_dbg)
+ return debuginfo__find_probe_location(dbg, pf);
+
+ /* Get the call frame information from this dwarf */
[PATCH] lightnvm: add full block direct to the gc list
We allocate gcb to queue full block to the gc list,
but gcb allocation may fail, if that happens, the
block will not get reclaimed. So add the full block
direct to the gc list, omit the queuing step.
Signed-off-by: Wenwei Tao
---
drivers/lightnvm/rrpc.c | 47 ++-
1 file changed, 10 insertions(+), 37 deletions(-)
diff --git a/drivers/lightnvm/rrpc.c b/drivers/lightnvm/rrpc.c
index 40b0309..27fb98d 100644
--- a/drivers/lightnvm/rrpc.c
+++ b/drivers/lightnvm/rrpc.c
@@ -475,24 +475,6 @@ static void rrpc_lun_gc(struct work_struct *work)
/* TODO: Hint that request queue can be started again */
}
-static void rrpc_gc_queue(struct work_struct *work)
-{
- struct rrpc_block_gc *gcb = container_of(work, struct rrpc_block_gc,
- ws_gc);
- struct rrpc *rrpc = gcb->rrpc;
- struct rrpc_block *rblk = gcb->rblk;
- struct nvm_lun *lun = rblk->parent->lun;
- struct rrpc_lun *rlun = &rrpc->luns[lun->id - rrpc->lun_offset];
-
- spin_lock(&rlun->lock);
- list_add_tail(&rblk->prio, &rlun->prio_list);
- spin_unlock(&rlun->lock);
-
- mempool_free(gcb, rrpc->gcb_pool);
- pr_debug("nvm: block '%lu' is full, allow GC (sched)\n",
- rblk->parent->id);
-}
-
static const struct block_device_operations rrpc_fops = {
.owner = THIS_MODULE,
};
@@ -620,39 +602,30 @@ err:
return NULL;
}
-static void rrpc_run_gc(struct rrpc *rrpc, struct rrpc_block *rblk)
-{
- struct rrpc_block_gc *gcb;
-
- gcb = mempool_alloc(rrpc->gcb_pool, GFP_ATOMIC);
- if (!gcb) {
- pr_err("rrpc: unable to queue block for gc.");
- return;
- }
-
- gcb->rrpc = rrpc;
- gcb->rblk = rblk;
-
- INIT_WORK(&gcb->ws_gc, rrpc_gc_queue);
- queue_work(rrpc->kgc_wq, &gcb->ws_gc);
-}
-
static void rrpc_end_io_write(struct rrpc *rrpc, struct rrpc_rq *rrqd,
sector_t laddr, uint8_t npages)
{
struct rrpc_addr *p;
struct rrpc_block *rblk;
struct nvm_lun *lun;
+ struct rrpc_lun *rlun;
int cmnt_size, i;
for (i = 0; i < npages; i++) {
p = &rrpc->trans_map[laddr + i];
rblk = p->rblk;
lun = rblk->parent->lun;
+ rlun = &rrpc->luns[lun->id - rrpc->lun_offset];
cmnt_size = atomic_inc_return(&rblk->data_cmnt_size);
- if (unlikely(cmnt_size == rrpc->dev->pgs_per_blk))
- rrpc_run_gc(rrpc, rblk);
+ if (unlikely(cmnt_size == rrpc->dev->pgs_per_blk)) {
+ pr_debug("nvm: block '%lu' is full, allow GC (sched)\n",
+ rblk->parent->id);
+ spin_lock(&rlun->lock);
+ list_add_tail(&rblk->prio, &rlun->prio_list);
+ spin_unlock(&rlun->lock);
+
+ }
}
}
--
1.8.3.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 1/6] INPUT: xpad: Add minimal support for Logitech G920 Wheel
On Dec 10 2015 or thereabouts, Dmitry Torokhov wrote: > On Thu, Dec 10, 2015 at 9:08 AM, Benjamin Tissoires > wrote: > > On Dec 09 2015 or thereabouts, Dmitry Torokhov wrote: > >> On Wed, Dec 9, 2015 at 5:23 PM, Dmitry Torokhov > >> wrote: > >> > On Thu, Nov 19, 2015 at 10:31 AM, Dmitry Torokhov > >> > wrote: > >> >> On Thu, Nov 19, 2015 at 02:50:51PM +0100, Jiri Kosina wrote: > >> >>> On Thu, 12 Nov 2015, Simon Wood wrote: > >> >>> > >> >>> > When plugged in the Logitech G920 wheel starts with USBID 046d:c261 > >> >>> > and behaviors as a vendor specific class. If a 'magic' byte sequence > >> >>> > is sent the wheel will detach and reconnect as a HID device with the > >> >>> > USBID 046d:c262. > >> >>> > > >> >>> > Signed-off-by: Simon Wood > >> >>> > >> >>> Adding Dmitry to CC. > >> >>> > >> >>> Dmitry, I am planning to take this through my tree together with the > >> >>> rest > >> >>> of the actual HID support for that device if you Ack this. > >> >> > >> >> Hmm, I have an incoming series for xbox that night clash with this... If > >> >> you'll put it in a clean branch off 4.3 I'd pull it and then get more > >> >> changes on top. > >> >> > >> >> Can we also change the subject as it is not about adding a minimal > >> >> support. Something like "Input: xpad - switch Logitech G920 Wheel into > >> >> HID mode" > >> >> > >> >> Otherwise: > >> >> > >> >> Acked-by: Dmitry Torokhov > >> > > >> > Hmm, looking sat this some more why are we waiting to switch device > >> > mode until after userspace opens input device instead of when we are > >> > executing driver probe()? > >> > > >> > >> Actually, thinking about it even more, why do we want to have this in > >> xpad.c? Have HID module handle both IDs and switch to HID mode if we > >> want HID to handle this device. I think we should revert/drop this > >> patch. > >> > > > > Hi Dmitry, > > Hi Benjamin, > > > > > IIRC, last time I saw an XBox-like controller, it doesn't register as a > > HID device at all. SO I think It will be hard to switch it into the HID > > mode from HID directly. > > Simon, can you confirm that the device does not contains any references > > to HID while in the XBox mode (lsusb -v should give enough information). > > > > Switching the device during probe in xpad.c makes a lot of sense > > however. > > It makes as much sense doing it in xpad as doing it from a random USB > network driver. I mean the only reason we are doing it from xpad is > because of name and the fat that it has usb_driver structure. Nobody > stops you from creating a tiny USB stub driver in hid portion that > would probe the "non-hid" device and switch it over to hid. > Jiri, I *think* this commit still is in your next pull request for Linus. We might want to drop it before it hits Linus' tree. We can still keep the HID work in place even if the device is not switched into the HID protocol at plug. Simon, do you mind looking into Dmitry's suggestion of having a clean, small usb device which loads itself when the G920 is plugged in and switches it immediately into the HID mode? Cheers, Benjamin -- 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] udf: avoid uninitialized variable use
On Fri 01-01-16 15:21:54, Arnd Bergmann wrote:
> A new warning about a real bug has come up from a recent cleanup:
>
> fs/udf/inode.c: In function 'udf_setup_indirect_aext':
> fs/udf/inode.c:1927:28: warning: 'adsize' may be used uninitialized in this
> function [-Wmaybe-uninitialized]
>
> If the alloc_type is neither ICBTAG_FLAG_AD_SHORT nor ICBTAG_FLAG_AD_LONG,
> the value of adsize is undefined. This changes the code to use zero for adsize
> in that case, which may be the correct solution, though I have not looked
> at the code in enough detail to know if it should be something else instead.
>
> Signed-off-by: Arnd Bergmann
> Fixes: fcea62babc81 ("udf: Factor out code for creating indirect extent")
> ---
> sorry for missing another instance the first time around. The warning is
> a bit unreliable and it seems in my first configuration I got it only
> for one of the two instances that show it in other configuration.
>
> After checking the remaining functions in this file for the same possible
> problem, I found that the other functions use either 'BUG()' or 'return -EIO'
> in the 'else' path, so I assume the two functions here should one of those
> as well, but I don't know which.
Callers of these functions make sure alloc_type is one of the two valid
ones. However for future-proofing you're right that probably we should
handle the invalid case as well. Setting adsize to zero is problematic -
not sure what the code would actually do but it wouldn't definitely work.
I'd just return -EIO. Attached is the patch I have merged.
Honza
>
> diff --git a/fs/udf/inode.c b/fs/udf/inode.c
> index 5b83351041a4..42f68dd7e6ef 100644
> --- a/fs/udf/inode.c
> +++ b/fs/udf/inode.c
> @@ -1890,6 +1890,8 @@ int udf_setup_indirect_aext(struct inode *inode, int
> block,
> adsize = sizeof(struct short_ad);
> else if (UDF_I(inode)->i_alloc_type == ICBTAG_FLAG_AD_LONG)
> adsize = sizeof(struct long_ad);
> + else
> + adsize = 0;
>
> neloc.logicalBlockNum = block;
> neloc.partitionReferenceNum = epos->block.partitionReferenceNum;
> @@ -1963,6 +1965,8 @@ int __udf_add_aext(struct inode *inode, struct
> extent_position *epos,
> adsize = sizeof(struct short_ad);
> else if (iinfo->i_alloc_type == ICBTAG_FLAG_AD_LONG)
> adsize = sizeof(struct long_ad);
> + else
> + adsize = 0;
>
> if (!epos->bh) {
> WARN_ON(iinfo->i_lenAlloc !=
>
--
Jan Kara
SUSE Labs, CR
>From 4f1b1519f7bec44ded3c2c4d46a2594c01446dc8 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann
Date: Fri, 1 Jan 2016 15:21:54 +0100
Subject: [PATCH] udf: avoid uninitialized variable use
A new warning has come up from a recent cleanup:
fs/udf/inode.c: In function 'udf_setup_indirect_aext':
fs/udf/inode.c:1927:28: warning: 'adsize' may be used uninitialized in this function [-Wmaybe-uninitialized]
If the alloc_type is neither ICBTAG_FLAG_AD_SHORT nor
ICBTAG_FLAG_AD_LONG, the value of adsize is undefined. Currently,
callers of these functions make sure alloc_type is one of the two valid
ones but for future proofing make sure we handle the case of invalid
alloc type as well. This changes the code to return -EIOin that case.
Signed-off-by: Arnd Bergmann
Fixes: fcea62babc81 ("udf: Factor out code for creating indirect extent")
Signed-off-by: Jan Kara
---
fs/udf/inode.c | 4
1 file changed, 4 insertions(+)
diff --git a/fs/udf/inode.c b/fs/udf/inode.c
index 846294891925..91d8fa9d87a4 100644
--- a/fs/udf/inode.c
+++ b/fs/udf/inode.c
@@ -1889,6 +1889,8 @@ int udf_setup_indirect_aext(struct inode *inode, int block,
adsize = sizeof(struct short_ad);
else if (UDF_I(inode)->i_alloc_type == ICBTAG_FLAG_AD_LONG)
adsize = sizeof(struct long_ad);
+ else
+ return -EIO;
neloc.logicalBlockNum = block;
neloc.partitionReferenceNum = epos->block.partitionReferenceNum;
@@ -1962,6 +1964,8 @@ int __udf_add_aext(struct inode *inode, struct extent_position *epos,
adsize = sizeof(struct short_ad);
else if (iinfo->i_alloc_type == ICBTAG_FLAG_AD_LONG)
adsize = sizeof(struct long_ad);
+ else
+ return -EIO;
if (!epos->bh) {
WARN_ON(iinfo->i_lenAlloc !=
--
2.6.2
Re: [PATCH 1/2] Document: i2c: Add a dt binding for mediatek MT2701 soc
On Mon, Jan 04, 2016 at 02:15:37PM +0800, Liguo Zhang wrote: > Add a dt binding for the MT2701 soc. > > Signed-off-by: Liguo Zhang This should probably go with the other patch via arm-soc, or? In that case: Acked-by: Wolfram Sang signature.asc Description: Digital signature
Re: [PATCH] quota: constify qtree_fmt_operations structures
On Fri 01-01-16 08:53:37, Julia Lawall wrote:
> The qtree_fmt_operations structures are never modified, so declare them as
> const.
>
> Done with the help of Coccinelle.
>
> Signed-off-by: Julia Lawall
Thanks! I've merged the patch to my tree.
Honza
>
> ---
> fs/ocfs2/quota.h|2 +-
> fs/ocfs2/quota_global.c |2 +-
> fs/quota/quota_v2.c |4 ++--
> include/linux/dqblk_qtree.h |2 +-
> 4 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/include/linux/dqblk_qtree.h b/include/linux/dqblk_qtree.h
> index 82a1652..ff8b553 100644
> --- a/include/linux/dqblk_qtree.h
> +++ b/include/linux/dqblk_qtree.h
> @@ -34,7 +34,7 @@ struct qtree_mem_dqinfo {
> unsigned int dqi_entry_size;/* Size of quota entry in quota file */
> unsigned int dqi_usable_bs; /* Space usable in block for quota data
> */
> unsigned int dqi_qtree_depth; /* Precomputed depth of quota tree */
> - struct qtree_fmt_operations *dqi_ops; /* Operations for entry
> manipulation */
> + const struct qtree_fmt_operations *dqi_ops; /* Operations for entry
> manipulation */
> };
>
> int qtree_write_dquot(struct qtree_mem_dqinfo *info, struct dquot *dquot);
> diff --git a/fs/quota/quota_v2.c b/fs/quota/quota_v2.c
> index 2aa012a..ed85d4f 100644
> --- a/fs/quota/quota_v2.c
> +++ b/fs/quota/quota_v2.c
> @@ -30,13 +30,13 @@ static void v2r1_mem2diskdqb(void *dp, struct dquot
> *dquot);
> static void v2r1_disk2memdqb(struct dquot *dquot, void *dp);
> static int v2r1_is_id(void *dp, struct dquot *dquot);
>
> -static struct qtree_fmt_operations v2r0_qtree_ops = {
> +static const struct qtree_fmt_operations v2r0_qtree_ops = {
> .mem2disk_dqblk = v2r0_mem2diskdqb,
> .disk2mem_dqblk = v2r0_disk2memdqb,
> .is_id = v2r0_is_id,
> };
>
> -static struct qtree_fmt_operations v2r1_qtree_ops = {
> +static const struct qtree_fmt_operations v2r1_qtree_ops = {
> .mem2disk_dqblk = v2r1_mem2diskdqb,
> .disk2mem_dqblk = v2r1_disk2memdqb,
> .is_id = v2r1_is_id,
> diff --git a/fs/ocfs2/quota.h b/fs/ocfs2/quota.h
> index b6d5133..d153e6e 100644
> --- a/fs/ocfs2/quota.h
> +++ b/fs/ocfs2/quota.h
> @@ -82,7 +82,7 @@ struct ocfs2_quota_chunk {
> extern struct kmem_cache *ocfs2_dquot_cachep;
> extern struct kmem_cache *ocfs2_qf_chunk_cachep;
>
> -extern struct qtree_fmt_operations ocfs2_global_ops;
> +extern const struct qtree_fmt_operations ocfs2_global_ops;
>
> struct ocfs2_quota_recovery *ocfs2_begin_quota_recovery(
> struct ocfs2_super *osb, int slot_num);
> diff --git a/fs/ocfs2/quota_global.c b/fs/ocfs2/quota_global.c
> index 44df24b..f0c7ae1 100644
> --- a/fs/ocfs2/quota_global.c
> +++ b/fs/ocfs2/quota_global.c
> @@ -123,7 +123,7 @@ static int ocfs2_global_is_id(void *dp, struct dquot
> *dquot)
> dquot->dq_id);
> }
>
> -struct qtree_fmt_operations ocfs2_global_ops = {
> +const struct qtree_fmt_operations ocfs2_global_ops = {
> .mem2disk_dqblk = ocfs2_global_mem2diskdqb,
> .disk2mem_dqblk = ocfs2_global_disk2memdqb,
> .is_id = ocfs2_global_is_id,
>
>
--
Jan Kara
SUSE Labs, CR
--
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/
[PATCHv2 1/3] regmap: core: Introduce regsiter stride order
Since the register stride should always equal to 2^N, and bit rotation is
much faster than multiplication and division. So introducing the stride
order and using bit rotation to get the offset of the register from the
index to improve the performance.
Signed-off-by: Xiubo Li
---
drivers/base/regmap/internal.h | 10 ++
drivers/base/regmap/regmap.c | 19 +--
2 files changed, 23 insertions(+), 6 deletions(-)
diff --git a/drivers/base/regmap/internal.h b/drivers/base/regmap/internal.h
index 3df9770..c22b04b 100644
--- a/drivers/base/regmap/internal.h
+++ b/drivers/base/regmap/internal.h
@@ -110,6 +110,7 @@ struct regmap {
/* number of bits to (left) shift the reg value when formatting*/
int reg_shift;
int reg_stride;
+ int reg_stride_order;
/* regcache specific members */
const struct regcache_ops *cache_ops;
@@ -263,4 +264,13 @@ static inline const char *regmap_name(const struct regmap
*map)
return map->name;
}
+static inline unsigned int regmap_get_offset(const struct regmap *map,
+unsigned int index)
+{
+ if (map->reg_stride_order >= 0)
+ return index << map->reg_stride_order;
+ else
+ return index * map->reg_stride;
+}
+
#endif
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index ee54e84..29d526e 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#define CREATE_TRACE_POINTS
#include "trace.h"
@@ -638,6 +639,10 @@ struct regmap *__regmap_init(struct device *dev,
map->reg_stride = config->reg_stride;
else
map->reg_stride = 1;
+ if (is_power_of_2(map->reg_stride))
+ map->reg_stride_order = ilog2(map->reg_stride);
+ else
+ map->reg_stride_order = -1;
map->use_single_read = config->use_single_rw || !bus || !bus->read;
map->use_single_write = config->use_single_rw || !bus || !bus->write;
map->can_multi_write = config->can_multi_write && bus && bus->write;
@@ -1308,7 +1313,7 @@ int _regmap_raw_write(struct regmap *map, unsigned int
reg,
if (map->writeable_reg)
for (i = 0; i < val_len / map->format.val_bytes; i++)
if (!map->writeable_reg(map->dev,
- reg + (i * map->reg_stride)))
+ reg + regmap_get_offset(map, i)))
return -EINVAL;
if (!map->cache_bypass && map->format.parse_val) {
@@ -1316,7 +1321,8 @@ int _regmap_raw_write(struct regmap *map, unsigned int
reg,
int val_bytes = map->format.val_bytes;
for (i = 0; i < val_len / val_bytes; i++) {
ival = map->format.parse_val(val + (i * val_bytes));
- ret = regcache_write(map, reg + (i * map->reg_stride),
+ ret = regcache_write(map,
+reg + regmap_get_offset(map, i),
ival);
if (ret) {
dev_err(map->dev,
@@ -1846,8 +1852,9 @@ int regmap_bulk_write(struct regmap *map, unsigned int
reg, const void *val,
goto out;
}
- ret = _regmap_write(map, reg + (i * map->reg_stride),
- ival);
+ ret = _regmap_write(map,
+ reg + regmap_get_offset(map, i),
+ ival);
if (ret != 0)
goto out;
}
@@ -2416,7 +2423,7 @@ int regmap_raw_read(struct regmap *map, unsigned int reg,
void *val,
* cost as we expect to hit the cache.
*/
for (i = 0; i < val_count; i++) {
- ret = _regmap_read(map, reg + (i * map->reg_stride),
+ ret = _regmap_read(map, reg + regmap_get_offset(map, i),
&v);
if (ret != 0)
goto out;
@@ -2568,7 +2575,7 @@ int regmap_bulk_read(struct regmap *map, unsigned int
reg, void *val,
} else {
for (i = 0; i < val_count; i++) {
unsigned int ival;
- ret = regmap_read(map, reg + (i * map->reg_stride),
+ ret = regmap_read(map, reg + regmap_get_offset(map, i),
&ival);
if (ret != 0)
return ret;
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@
[PATCHv2 0/3] regmap: Introduce regsiter stride order
Please ignore the V1 series. Changed in V2: - Introduce regsiter stride order by continue supporting non power of two strides. Xiubo Li (3): regmap: core: Introduce regsiter stride order regcache: Introduce the index parsing API by stride order regcache: flat: Introduce register strider order drivers/base/regmap/internal.h | 16 drivers/base/regmap/regcache-flat.c | 20 +++- drivers/base/regmap/regmap.c| 19 +-- 3 files changed, 44 insertions(+), 11 deletions(-) -- 1.8.3.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 4.4-rc5 v22 4/4] ARM: Allow IPI_CPU_BACKTRACE to exploit FIQ
On 20/12/15 22:12, kbuild test robot wrote: Hi Daniel, [auto build test ERROR on v4.4-rc5] [also build test ERROR on next-20151218] [cannot apply to tip/irq/core] url: https://github.com/0day-ci/linux/commits/Daniel-Thompson/irq-arm-Use-FIQ-for-NMI-backtrace-when-possible/20151221-045854 config: arm-iop-adma (attached as .config) reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm All errors (new ones prefixed by >>): arch/arm/kernel/traps.c: In function 'handle_fiq_as_nmi': arch/arm/kernel/traps.c:489:2: error: implicit declaration of function 'handle_arch_irq' [-Werror=implicit-function-declaration] handle_arch_irq(regs); ^ cc1: some warnings being treated as errors Thanks. I'll look at this. vim +/handle_arch_irq +489 arch/arm/kernel/traps.c 483 * Either the interrupt controller supports FIQ, meaning it will 484 * do the right thing with this call, or we will end up treating a 485 * spurious FIQ (which is normally fatal) as though it were an IRQ 486 * which, although it risks deadlock, still gives us a sporting 487 * chance of surviving long enough to log errors. 488 */ > 489 handle_arch_irq(regs); 490 491 nmi_exit(); 492 --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation -- 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/
[PATCHv2 3/3] regcache: flat: Introduce register strider order
Here we introduce regcache_flat_get_index(), which using register
stride order and bit rotation, will save some memory spaces for
flat cache. Though this will also lost some access performance,
since the bit rotation is used to get the index of the cache array,
and this could be ingored for memory I/O accessing.
Signed-off-by: Xiubo Li
---
drivers/base/regmap/regcache-flat.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/base/regmap/regcache-flat.c
b/drivers/base/regmap/regcache-flat.c
index 686c9e0..3ee7255 100644
--- a/drivers/base/regmap/regcache-flat.c
+++ b/drivers/base/regmap/regcache-flat.c
@@ -16,20 +16,30 @@
#include "internal.h"
+static inline unsigned int regcache_flat_get_index(const struct regmap *map,
+ unsigned int reg)
+{
+ return regcache_get_index_by_order(map, reg);
+}
+
static int regcache_flat_init(struct regmap *map)
{
int i;
unsigned int *cache;
- map->cache = kcalloc(map->max_register + 1, sizeof(unsigned int),
-GFP_KERNEL);
+ if (!map || map->reg_stride_order < 0)
+ return -EINVAL;
+
+ map->cache = kcalloc(regcache_flat_get_index(map, map->max_register)
++ 1, sizeof(unsigned int), GFP_KERNEL);
if (!map->cache)
return -ENOMEM;
cache = map->cache;
for (i = 0; i < map->num_reg_defaults; i++)
- cache[map->reg_defaults[i].reg] = map->reg_defaults[i].def;
+ cache[regcache_flat_get_index(map, map->reg_defaults[i].reg)] =
+ map->reg_defaults[i].def;
return 0;
}
@@ -47,7 +57,7 @@ static int regcache_flat_read(struct regmap *map,
{
unsigned int *cache = map->cache;
- *value = cache[reg];
+ *value = cache[regcache_flat_get_index(map, reg)];
return 0;
}
@@ -57,7 +67,7 @@ static int regcache_flat_write(struct regmap *map, unsigned
int reg,
{
unsigned int *cache = map->cache;
- cache[reg] = value;
+ cache[regcache_flat_get_index(map, reg)] = value;
return 0;
}
--
1.8.3.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: RCU stall and the system boot hang with nfsroot
On Fri, Jan 1, 2016 at 3:49 AM, Paul E. McKenney
wrote:
> On Wed, Dec 30, 2015 at 09:41:45AM -0800, Paul E. McKenney wrote:
>> On Wed, Dec 30, 2015 at 03:03:33PM +0800, Aaron Ma wrote:
>> > On Wed, Dec 30, 2015 at 7:42 AM, Paul E. McKenney
>> > wrote:
>
> [ . . . ]
>
>> > cfg80211: Calling CRDA to update world regulatory domain
>> > cfg80211: Calling CRDA to update world regulatory domain
>> > cfg80211: Exceeded CRDA call max attempts. Not calling CRDA
>> > INFO: rcu_preempt detected stalls on CPUs/tasks:
>> > 71: (0 ticks this GP) idle=1ac/0/0 softirq=0/0 fqs=0
>> > (detected by 62, t=26002 jiffies, g=3735, c=3734, q=366014)
>> > Task dump for CPU 71:
>> > swapper/71 R running task0 0 1 0x0020
>> > 81492587 8804633cbe58 814f21d7 0004
>> > 0004 e8fffb405310 820dc5c0 8804633cbea8
>> > 8181db85 0046
>> > Call Trace:
>> > [] ? debug_smp_processor_id+0x17/0x20
>> > [] ? intel_idle+0x137/0x140
>> > [] ? cpuidle_enter_state+0x65/0x3e0
>> > [] ? cpuidle_enter+0x17/0x20
>> > [] ? cpu_startup_entry+0x33d/0x630
>> > [] ? start_secondary+0x12e/0x140
>> > rcu_preempt kthread starved for 26002 jiffies!
>> > rcu_check_gp_kthread_starvation --->show task:
>> > rcu_preempt S 880456413c68 0 8 2 0x
>> > 880456413c68 8804564025d0 d7a0 880456b18000
>> > 8804564025d0 880456413c38 81492587 880456413c58
>> > 880456414000 8804564025d0 880456413cb8 880869dce500
>> > Call Trace:
>> > [] ? debug_smp_processor_id+0x17/0x20
>> > [] schedule+0x3f/0xd0
>> > [] schedule_timeout+0x189/0x3f0
>> > [] ? swait_prepare+0x24/0x90
>> > [] ? timer_cpu_notify+0x190/0x190
>> > [] ? swait_prepare+0x5b/0x90
>> > [] rcu_gp_kthread+0x8a8/0x2190
>> > [] ? trace_hardirqs_on+0xd/0x10
>> > [] ? __schedule+0x4af/0x1180
>> > [] ? call_rcu_sched+0x20/0x20
>> > [] kthread+0xe4/0x100
>> > [] ? trace_hardirqs_on+0xd/0x10
>> > [] ? kthread_create_on_node+0x240/0x240
>> > [] ret_from_fork+0x42/0x70
>> > [] ? kthread_create_on_node+0x240/0x240
>> > rcu_check_gp_kthread_starvation --->end
>> >
>> > It seems wait in rcu_gp_kthread. it should be no task blocked right?
>> > If so, why the swait_event_interruptible_timeout is not awaken? the
>> > timeout is CONFIG_HZ=1000.
>>
>> Given that this happens at boot, perhaps ftrace is a good next step.
>> The thought would be to enable ftrace via the kernel boot parameters
>> for the timers.
>>
>> And how often does this problem occur?
>
> And does the following diagnostic patch help? Its expected behavior
> would be to turn a hard hang into something that recovered in a few
> minutes, while giving a few stall-warning splats.
>
> Thanx, Paul
>
>
>
> commit 7798a5efb2acabfa3ca788dd9b5b118eb1bff443
> Author: Paul E. McKenney
> Date: Thu Dec 31 08:48:36 2015 -0800
>
> rcu: Awaken grace-period kthread when stalled
>
> Recent kernels can fail to awaken the grace-period kthread for
> quiescent-state forcing. This commit is a crude hack that does
> a wakeup any time a stall is detected.
>
> Signed-off-by: Paul E. McKenney
>
> diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> index 4b3de6718f7c..51da7ef3561f 100644
> --- a/kernel/rcu/tree.c
> +++ b/kernel/rcu/tree.c
> @@ -1225,8 +1225,10 @@ static void rcu_check_gp_kthread_starvation(struct
> rcu_state *rsp)
>rsp->gp_flags,
>gp_state_getname(rsp->gp_state), rsp->gp_state,
>rsp->gp_kthread ? rsp->gp_kthread->state : ~0);
> - if (rsp->gp_kthread)
> + if (rsp->gp_kthread) {
> sched_show_task(rsp->gp_kthread);
> + wake_up_process(rsp->gp_kthread);
> + }
> }
> }
Sorry for late response because of holiday.
During my knowledge, now this issue is splitted to 2 issues.
First, there is a mistake in the kernel I used.
I used kernel is changed by someone else, and it ported a patch:
Author: Thomas Gleixner
Date: Tue Apr 14 21:08:54 2015 +
tick: sched: Force tick interrupt and get rid of softirq magic
commit 0ff53d09642204c648424def0caa9117e7a3caaf upstream
static ktime_t tick_nohz_stop_sched_tick(struct tick_sched *ts,
ktime_t now, int cpu)
{
@@ -691,22 +705,18 @@ static ktime_t tick_nohz_stop_sched_tick(struct
tick_sched *ts,
if (ts->nohz_mode == NOHZ_MODE_HIGHRES)
hrtimer_cancel(&ts->sched_timer);
goto out;
- }
+}
- if (ts->nohz_mode == NOHZ_MODE_HIGHRES) {
- hrtimer_start(&ts->sched_timer, expires,
-
[PATCHv2 2/3] regcache: Introduce the index parsing API by stride order
Here introduces regcache_get_index_by_order() for regmap cache,
which uses the register stride order and bit rotation, to improve
the performance.
Signed-off-by: Xiubo Li
---
drivers/base/regmap/internal.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/base/regmap/internal.h b/drivers/base/regmap/internal.h
index c22b04b..5c79526 100644
--- a/drivers/base/regmap/internal.h
+++ b/drivers/base/regmap/internal.h
@@ -273,4 +273,10 @@ static inline unsigned int regmap_get_offset(const struct
regmap *map,
return index * map->reg_stride;
}
+static inline unsigned int regcache_get_index_by_order(const struct regmap
*map,
+ unsigned int reg)
+{
+ return reg >> map->reg_stride_order;
+}
+
#endif
--
1.8.3.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: [linux-sunxi] Re: [PATCH v3 2/3] ARM: dts: sun8i: Add Allwinner A83T dtsi
Hi,
On Sat, Dec 19, 2015 at 11:57:03AM +0100, Hans de Goede wrote:
> >>+ memory {
> >>+ reg = <0x4000 0x8000>;
> >>+ };
> >
> >Is mainline u-boot usable ? If so, you can remove that node entirely.
>
> mainline u-boot works for me when cold-booting from a sdcard, so I consider
> it usable :)
I'm glad we have the same definition of usable ;)
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
Re: [PATCH 4.4-rc5 v22 4/4] ARM: Allow IPI_CPU_BACKTRACE to exploit FIQ
On 20/12/15 22:52, kbuild test robot wrote: Hi Daniel, [auto build test ERROR on v4.4-rc5] [also build test ERROR on next-20151218] [cannot apply to tip/irq/core] url: https://github.com/0day-ci/linux/commits/Daniel-Thompson/irq-arm-Use-FIQ-for-NMI-backtrace-when-possible/20151221-045854 config: arm-socfpga_defconfig (attached as .config) reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # save the attached .config to linux build tree make.cross ARCH=arm All error/warnings (new ones prefixed by >>): In file included from include/uapi/linux/stddef.h:1:0, from include/linux/stddef.h:4, from include/uapi/linux/posix_types.h:4, from include/uapi/linux/types.h:13, from include/linux/types.h:5, from include/linux/list.h:4, from include/linux/module.h:9, from arch/arm/kernel/smp.c:10: arch/arm/kernel/smp.c: In function 'raise_nmi': include/linux/compiler.h:484:38: error: call to '__compiletime_assert_766' declared with attribute error: BUILD_BUG_ON failed: SMP_IPI_FIQ_MASK != BIT(IPI_CPU_BACKTRACE) _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) ^ include/linux/compiler.h:467:4: note: in definition of macro '__compiletime_assert' prefix ## suffix();\ ^ include/linux/compiler.h:484:2: note: in expansion of macro '_compiletime_assert' _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__) ^ include/linux/bug.h:50:37: note: in expansion of macro 'compiletime_assert' #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) ^ include/linux/bug.h:74:2: note: in expansion of macro 'BUILD_BUG_ON_MSG' BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition) ^ arch/arm/kernel/smp.c:766:2: note: in expansion of macro 'BUILD_BUG_ON' BUILD_BUG_ON(SMP_IPI_FIQ_MASK != BIT(IPI_CPU_BACKTRACE)); This should be a false alarm or at least, the BUILD_BUG_ON() is doing exactly what it was intended to. I forgot to mention it in the covering letter (and will fix next time) but my patchset requires a fix from Marc Zyngier which changes the numeric value of IPI_CPU_BACKTRACE[1]. Daniel. 1: http://thread.gmane.org/gmane.linux.ports.arm.kernel/464985 -- 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: net-libertas: Better exception handling in if_spi_host_to_card_worker()
On 03-01-16 16:18, Rafał Miłecki wrote:
> On 3 January 2016 at 10:36, Arend van Spriel wrote:
>> On 02-01-16 12:21, SF Markus Elfring wrote:
Did you look at the resulting assembly code for different target
architectures?
>>>
>>> Not yet. - Which execution system variants would you recommend for
>>> further comparisons?
>>
>> Guess x86{,_64} and arm would be good candidates, ie. CISC vs. RISC.
>
> Oh, don't forget about MIPS with its fancy branches handling. You know
> about it, don't you?
You are asking me, right ;-) ? I have come across my share of MIPS
platforms here at Broadcom, but I still try to avoid them as much as
possible.
> I'm against this patch as well.
and counting... :-p
Regards,
Arend
--
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/13] arm64: kvm: deal with kernel symbols outside of linear mapping
Hi Ard,
On 30/12/15 15:26, Ard Biesheuvel wrote:
> KVM on arm64 uses a fixed offset between the linear mapping at EL1 and
> the HYP mapping at EL2. Before we can move the kernel virtual mapping
> out of the linear mapping, we have to make sure that references to kernel
> symbols that are accessed via the HYP mapping are translated to their
> linear equivalent.
>
> To prevent inadvertent direct references from sneaking in later, change
> the type of all extern declarations to HYP kernel symbols to the opaque
> 'struct kvm_ksym', which does not decay to a pointer type like char arrays
> and function references. This is not bullet proof, but at least forces the
> user to take the address explicitly rather than referencing it directly.
>
> Signed-off-by: Ard Biesheuvel
This looks good to me, a few comments below.
> ---
> arch/arm/include/asm/kvm_asm.h | 2 ++
> arch/arm/include/asm/kvm_mmu.h | 2 ++
> arch/arm/kvm/arm.c | 9 +
> arch/arm/kvm/mmu.c | 12 +--
> arch/arm64/include/asm/kvm_asm.h | 21 +++-
> arch/arm64/include/asm/kvm_mmu.h | 2 ++
> arch/arm64/include/asm/virt.h| 4
> arch/arm64/kernel/vmlinux.lds.S | 4 ++--
> arch/arm64/kvm/debug.c | 4 +++-
> virt/kvm/arm/vgic-v3.c | 2 +-
> 10 files changed, 34 insertions(+), 28 deletions(-)
>
> diff --git a/arch/arm/include/asm/kvm_asm.h b/arch/arm/include/asm/kvm_asm.h
> index 194c91b610ff..484ffdf7c70b 100644
> --- a/arch/arm/include/asm/kvm_asm.h
> +++ b/arch/arm/include/asm/kvm_asm.h
> @@ -99,6 +99,8 @@ extern void __kvm_tlb_flush_vmid_ipa(struct kvm *kvm,
> phys_addr_t ipa);
> extern void __kvm_tlb_flush_vmid(struct kvm *kvm);
>
> extern int __kvm_vcpu_run(struct kvm_vcpu *vcpu);
> +
> +extern char __hyp_idmap_text_start[], __hyp_idmap_text_end[];
> #endif
>
> #endif /* __ARM_KVM_ASM_H__ */
> diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
> index 405aa1883307..412b363f79e9 100644
> --- a/arch/arm/include/asm/kvm_mmu.h
> +++ b/arch/arm/include/asm/kvm_mmu.h
> @@ -30,6 +30,8 @@
> #define HYP_PAGE_OFFSET PAGE_OFFSET
> #define KERN_TO_HYP(kva) (kva)
>
> +#define kvm_ksym_ref(kva)(kva)
> +
> /*
> * Our virtual mapping for the boot-time MMU-enable code. Must be
> * shared across all the page-tables. Conveniently, we use the vectors
> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
> index e06fd299de08..014b542ea658 100644
> --- a/arch/arm/kvm/arm.c
> +++ b/arch/arm/kvm/arm.c
> @@ -427,7 +427,7 @@ static void update_vttbr(struct kvm *kvm)
>* shareable domain to make sure all data structures are
>* clean.
>*/
> - kvm_call_hyp(__kvm_flush_vm_context);
> + kvm_call_hyp(kvm_ksym_ref(__kvm_flush_vm_context));
> }
>
> kvm->arch.vmid_gen = atomic64_read(&kvm_vmid_gen);
> @@ -600,7 +600,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu, struct
> kvm_run *run)
> __kvm_guest_enter();
> vcpu->mode = IN_GUEST_MODE;
>
> - ret = kvm_call_hyp(__kvm_vcpu_run, vcpu);
> + ret = kvm_call_hyp(kvm_ksym_ref(__kvm_vcpu_run), vcpu);
>
> vcpu->mode = OUTSIDE_GUEST_MODE;
> /*
> @@ -969,7 +969,7 @@ static void cpu_init_hyp_mode(void *dummy)
> pgd_ptr = kvm_mmu_get_httbr();
> stack_page = __this_cpu_read(kvm_arm_hyp_stack_page);
> hyp_stack_ptr = stack_page + PAGE_SIZE;
> - vector_ptr = (unsigned long)__kvm_hyp_vector;
> + vector_ptr = (unsigned long)kvm_ksym_ref(__kvm_hyp_vector);
>
> __cpu_init_hyp_mode(boot_pgd_ptr, pgd_ptr, hyp_stack_ptr, vector_ptr);
>
> @@ -1061,7 +1061,8 @@ static int init_hyp_mode(void)
> /*
>* Map the Hyp-code called directly from the host
>*/
> - err = create_hyp_mappings(__kvm_hyp_code_start, __kvm_hyp_code_end);
> + err = create_hyp_mappings(kvm_ksym_ref(__kvm_hyp_code_start),
> + kvm_ksym_ref(__kvm_hyp_code_end));
> if (err) {
> kvm_err("Cannot map world-switch code\n");
> goto out_free_mappings;
> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
> index 7dace909d5cf..7c448b943e3a 100644
> --- a/arch/arm/kvm/mmu.c
> +++ b/arch/arm/kvm/mmu.c
> @@ -31,8 +31,6 @@
>
> #include "trace.h"
>
> -extern char __hyp_idmap_text_start[], __hyp_idmap_text_end[];
> -
> static pgd_t *boot_hyp_pgd;
> static pgd_t *hyp_pgd;
> static pgd_t *merged_hyp_pgd;
> @@ -63,7 +61,7 @@ static bool memslot_is_logging(struct kvm_memory_slot
> *memslot)
> */
> void kvm_flush_remote_tlbs(struct kvm *kvm)
> {
> - kvm_call_hyp(__kvm_tlb_flush_vmid, kvm);
> + kvm_call_hyp(kvm_ksym_ref(__kvm_tlb_flush_vmid), kvm);
Any chance we could bury kvm_ksym_ref in kvm_call_hyp? It may make the
change more readable, but I have the feeling it would require an
intermediate #define...
> }
>
> sta
Re: [PATCH v1 1/3] ARM64 LPC: indirect ISA PORT IO introduced
On Wed, Dec 30, 2015 at 10:42:50AM +0100, Arnd Bergmann wrote: > On Wednesday 30 December 2015 17:28:20 Rongrong Zou wrote: > > >> > > > > > > config ARM64_INDIRECT_PIO > > > bool > > > help > > > Any driver that provides indirect ISA I/O port access should > > > select > > > this symbol > > > > > > > > > > config HISILICON_HI123456_LPC > > > bool "Workaround for nonstandard ISA I/O space on Hisilicon > > > Hi123456 SoC" > > > depends on ARCH_HISI || COMPILE_TEST > > > select ARM64_INDIRECT_PIO > > > help > > > ... > > Can it be a submenu of "Platform selection--->Hisilicon SoC Family"? > > The first should be in the main Kconfig file for arm64, the second one depends > on where we put the respective code. I'd say both the Kconfig entry and the > file > can go into drivers/bus, but arch/arm64/kernel/ is also fine with me. Unsurprisingly, I'd *much* prefer drivers/bus/ ! Will -- 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 v3 4/8] dt-bindings: Add a binding for Mediatek Video Encoder
Add a DT binding documentation of Video Encoder for the
MT8173 SoC from Mediatek.
Signed-off-by: Tiffany Lin
---
.../devicetree/bindings/media/mediatek-vcodec.txt | 58
1 file changed, 58 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/mediatek-vcodec.txt
diff --git a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
new file mode 100644
index 000..5cc35ae
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt
@@ -0,0 +1,58 @@
+Mediatek Video Codec
+
+Mediatek Video Codec is the video codec hw present in Mediatek SoCs which
+supports high resolution encoding functionalities.
+
+Required properties:
+- compatible : "mediatek,mt8173-vcodec-enc" for encoder
+- reg : Physical base address of the video codec registers and length of
+ memory mapped region.
+- interrupts : interrupt number to the cpu.
+- mediatek,larb : must contain the local arbiters in the current Socs.
+- clocks : list of clock specifiers, corresponding to entries in
+ the clock-names property;
+- clock-names: must contain "vencpll", "venc_lt_sel", "vcodecpll_370p5_ck"
+- iommus : list of iommus specifiers should be enabled for hw encode.
+ There are 2 cells needed to enable/disable iommu.
+ The first one is local arbiter index(larbid), and the other is port
+ index(portid) within local arbiter. Specifies the larbid and portid
+ as defined in dt-binding/memory/mt8173-larb-port.h.
+- mediatek,vpu : the node of video processor unit
+
+Example:
+vcodec_enc: vcodec@0x18002000 {
+compatible = "mediatek,mt8173-vcodec-enc";
+reg = <0 0x18002000 0 0x1000>,/*VENC_SYS*/
+ <0 0x19002000 0 0x1000>;/*VENC_LT_SYS*/
+interrupts = ,
+ ;
+mediatek,larb = <&larb3>,
+ <&larb5>;
+iommus = <&iommu M4U_PORT_VENC_RCPU>,
+ <&iommu M4U_PORT_VENC_REC>,
+ <&iommu M4U_PORT_VENC_BSDMA>,
+ <&iommu M4U_PORT_VENC_SV_COMV>,
+ <&iommu M4U_PORT_VENC_RD_COMV>,
+ <&iommu M4U_PORT_VENC_CUR_LUMA>,
+ <&iommu M4U_PORT_VENC_CUR_CHROMA>,
+ <&iommu M4U_PORT_VENC_REF_LUMA>,
+ <&iommu M4U_PORT_VENC_REF_CHROMA>,
+ <&iommu M4U_PORT_VENC_NBM_RDMA>,
+ <&iommu M4U_PORT_VENC_NBM_WDMA>,
+ <&iommu M4U_PORT_VENC_RCPU_SET2>,
+ <&iommu M4U_PORT_VENC_REC_FRM_SET2>,
+ <&iommu M4U_PORT_VENC_BSDMA_SET2>,
+ <&iommu M4U_PORT_VENC_SV_COMA_SET2>,
+ <&iommu M4U_PORT_VENC_RD_COMA_SET2>,
+ <&iommu M4U_PORT_VENC_CUR_LUMA_SET2>,
+ <&iommu M4U_PORT_VENC_CUR_CHROMA_SET2>,
+ <&iommu M4U_PORT_VENC_REF_LUMA_SET2>,
+ <&iommu M4U_PORT_VENC_REC_CHROMA_SET2>;
+mediatek,vpu = <&vpu>;
+clocks = <&apmixedsys CLK_APMIXED_VENCPLL>,
+ <&topckgen CLK_TOP_VENC_LT_SEL>,
+ <&topckgen CLK_TOP_VCODECPLL_370P5>;
+clock-names = "vencpll",
+ "venc_lt_sel",
+ "vcodecpll_370p5_ck";
+ };
--
1.7.9.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/
[PATCH v3 0/8] Add MT8173 Video Encoder Driver and VPU Driver
== Introduction == The purpose of this series is to add the driver for video codec hw embedded in the Mediatek's MT8173 SoCs. Mediatek Video Codec is able to handle video encoding of in a range of formats. This RFC also include VPU driver. Mediatek Video Codec driver rely on VPU driver to load, communicate with VPU. Internally the driver uses videobuf2 framework and MTK IOMMU and MTK SMI. MTK IOMMU and MTK SMI[1] have not yet been merged, but we wanted to start discussion about the driver earlier so it could be merged sooner. The driver posted here is the initial version, so I suppose it will require more work. [1]https://patchwork.kernel.org/patch/7880291/ == Device interface == In principle the driver bases on memory-to-memory framework: it provides a single video node and each opened file handle gets its own private context with separate buffer queues. Each context consist of 2 buffer queues: OUTPUT (for source buffers, i.e. raw video frames) and CAPTURE (for destination buffers, i.e. encoded video frames). The process of encoding video data from stream is a bit more complicated than typical memory-to-memory processing. We base on memory-to-memory framework and add the complicated part in our vb2 and v4l2 callback functionss. So we can base on well done m2m memory-to-memory framework, reduce duplicate code and make our driver code simple. == VPU (Video Processor Unit) == The VPU driver for hw video codec embedded in Mediatek's MT8173 SOCs. It is able to handle video decoding/encoding of in a range of formats. The driver provides with VPU firmware download, memory management and the communication interface between CPU and VPU. For VPU initialization, it will create virtual memory for CPU access and IOMMU address for vcodec hw device access. When a decode/encode instance opens a device node, vpu driver will download vpu firmware to the device. A decode/encode instant will decode/encode a frame using VPU interface to interrupt vpu to handle decoding/encoding jobs. Please have a look at the code and comments will be very much appreciated. Change in v3: 1.Refine code to pass v4l2-compliance test, now it still has 2 issues 2.Refine code according to latest MTK IOMMU patches[1] 3.Remove MFC51 specific CIDs and add MTK specific CIDs for for keyframe and skip I-frame 4.Refine code according to review comments Below is the v1.6 version v4l2-compliance report for the mt8173 encoder driver. Now there are still 2 test fail in v1.6. For VIDIOC_REQBUFS/CREATE_BUFS/QUERYBUF, we directly use v4l2_m2m_ioctl_* functions, but it still fail. It pass in kernel 3.18 but fail in kernel 4.4. We will try v1.8 in next version. VIDIOC_EXPBUF is becuase we support all three memory types VB2_DMABUF, VB2_MMAP and VB2_USERPTR. VIDIOC_EXPBUF only allowed when only VB2_MMAP supported. localhost ~ # /usr/bin/v4l2-compliance -d /dev/video1 Driver Info: Driver name : mtk-vcodec-en Card type : platform:mt817 Bus info : platform:mt817 Driver version: 4.4.0 Capabilities : 0x84204000 Video Memory-to-Memory Multiplanar Streaming Extended Pix Format Device Capabilities Device Caps : 0x04204000 Video Memory-to-Memory Multiplanar Streaming Extended Pix Format Compliance test for device /dev/video1 (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 (Not Supported) Input ioctls: test VIDIOC_G/S_TUNER/ENUM_FREQ_BANDS: 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 (Not Supported) test VIDIOC_G/S_AUDIO: OK (Not Supported) Inputs: 0 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 (Not Supported) 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) Control ioctls: test VIDIOC_QUERYCTRL/MENU: OK test VIDIOC_G/S_CTRL: OK test VIDIOC_G/S/TRY_EXT_CTRLS: OK
[PATCH v3 7/8] media: vcodec: mediatek: Add Mediatek H264 Video Encoder Driver
Add h264 encoder driver for MT8173
Signed-off-by: Daniel Hsiao
Signed-off-by: Tiffany Lin
---
drivers/media/platform/mtk-vcodec/Makefile |3 +-
.../media/platform/mtk-vcodec/h264_enc/Makefile|6 +
.../platform/mtk-vcodec/h264_enc/venc_h264_if.c| 530
.../platform/mtk-vcodec/h264_enc/venc_h264_if.h| 165 ++
.../platform/mtk-vcodec/h264_enc/venc_h264_vpu.c | 310
.../platform/mtk-vcodec/h264_enc/venc_h264_vpu.h | 30 ++
drivers/media/platform/mtk-vcodec/venc_drv_if.c|3 +
7 files changed, 1046 insertions(+), 1 deletion(-)
create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/Makefile
create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.c
create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.h
create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.c
create mode 100644 drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_vpu.h
diff --git a/drivers/media/platform/mtk-vcodec/Makefile
b/drivers/media/platform/mtk-vcodec/Makefile
index f4ef502..f47dfc7 100644
--- a/drivers/media/platform/mtk-vcodec/Makefile
+++ b/drivers/media/platform/mtk-vcodec/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk_vcodec_intr.o \
mtk_vcodec_enc_pm.o \
venc_drv_if.o
-obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += vp8_enc/
+
+obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += vp8_enc/ h264_enc/
ccflags-y += -I$(srctree)/drivers/media/platform/mtk-vpu
diff --git a/drivers/media/platform/mtk-vcodec/h264_enc/Makefile
b/drivers/media/platform/mtk-vcodec/h264_enc/Makefile
new file mode 100644
index 000..765b45f
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/h264_enc/Makefile
@@ -0,0 +1,6 @@
+obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += venc_h264_if.o venc_h264_vpu.o
+
+ccflags-y += \
+-I$(srctree)/drivers/media/platform/mtk-vcodec/ \
+-I$(srctree)/drivers/media/platform/mtk-vcodec/h264_enc \
+-I$(srctree)/drivers/media/platform/mtk-vpu
diff --git a/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.c
b/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.c
new file mode 100644
index 000..14990ce
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/h264_enc/venc_h264_if.c
@@ -0,0 +1,530 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ * Author: Jungchang Tsao
+ * Daniel Hsiao
+ * PoChun Lin
+ *
+ * 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 "mtk_vcodec_drv.h"
+#include "mtk_vcodec_util.h"
+#include "mtk_vcodec_intr.h"
+#include "mtk_vcodec_enc.h"
+#include "mtk_vcodec_pm.h"
+#include "mtk_vpu.h"
+
+#include "venc_h264_if.h"
+#include "venc_h264_vpu.h"
+
+#define VENC_PIC_BITSTREAM_BYTE_CNT 0x0098
+
+static inline void h264_write_reg(struct venc_h264_inst *inst, u32 addr,
+ u32 val)
+{
+ writel(val, inst->hw_base + addr);
+}
+
+static inline u32 h264_read_reg(struct venc_h264_inst *inst, u32 addr)
+{
+ return readl(inst->hw_base + addr);
+}
+
+enum venc_h264_irq_status {
+ H264_IRQ_STATUS_ENC_SPS_INT = (1 << 0),
+ H264_IRQ_STATUS_ENC_PPS_INT = (1 << 1),
+ H264_IRQ_STATUS_ENC_FRM_INT = (1 << 2),
+};
+
+static void h264_enc_free_work_buf(struct venc_h264_inst *inst)
+{
+ int i;
+
+ mtk_vcodec_debug_enter(inst);
+
+ /* Except the RC_CODE and SKIP_FRAME buffers,
+* other buffers need to be freed by AP.
+*/
+ for (i = 0; i < VENC_H264_VPU_WORK_BUF_MAX; i++) {
+ if ((i != VENC_H264_VPU_WORK_BUF_RC_CODE) &&
+ (i != VENC_H264_VPU_WORK_BUF_SKIP_FRAME))
+ if (inst->work_bufs[i].va != NULL)
+ mtk_vcodec_mem_free(inst->ctx,
+ &inst->work_bufs[i]);
+ }
+
+ if (inst->pps_buf.va != NULL)
+ mtk_vcodec_mem_free(inst->ctx, &inst->pps_buf);
+
+ mtk_vcodec_debug_leave(inst);
+}
+
+static int h264_enc_alloc_work_buf(struct venc_h264_inst *inst, void *param)
+{
+ int i;
+ int ret = 0;
+ struct venc_h264_vpu_buf *wb = inst->vpu_inst.drv->work_bufs;
+ struct venc_enc_prm *enc_param = param;
+
+ mtk_vcodec_debug_enter(inst);
+
+ for (i = 0; i < VENC_H264_VPU_WORK_BUF_MAX; i++) {
+ /*
+* This 'wb' structure is set by VPU side and shared to AP for
+* buffer allocation and IO virtual addr map
[PATCH v3 5/8] media: vcodec: mediatek: Add Mediatek V4L2 Video Encoder Driver
From: Andrew-CT Chen Add v4l2 layer encoder driver for MT8173 Signed-off-by: Tiffany Lin --- drivers/media/platform/Kconfig | 11 + drivers/media/platform/Makefile|2 + drivers/media/platform/mtk-vcodec/Makefile |8 + drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h | 391 ++ drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c | 1433 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.h | 46 + .../media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c | 454 +++ .../media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c | 122 ++ .../media/platform/mtk-vcodec/mtk_vcodec_intr.c| 102 ++ .../media/platform/mtk-vcodec/mtk_vcodec_intr.h| 29 + drivers/media/platform/mtk-vcodec/mtk_vcodec_pm.h | 26 + .../media/platform/mtk-vcodec/mtk_vcodec_util.c| 106 ++ .../media/platform/mtk-vcodec/mtk_vcodec_util.h| 85 ++ drivers/media/platform/mtk-vcodec/venc_drv_base.h | 62 + drivers/media/platform/mtk-vcodec/venc_drv_if.c| 100 ++ drivers/media/platform/mtk-vcodec/venc_drv_if.h| 175 +++ drivers/media/platform/mtk-vcodec/venc_ipi_msg.h | 212 +++ include/uapi/linux/v4l2-controls.h |4 + 18 files changed, 3368 insertions(+) create mode 100644 drivers/media/platform/mtk-vcodec/Makefile create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.c create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc.h create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_drv.c create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_enc_pm.c create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.c create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_intr.h create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_pm.h create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.c create mode 100644 drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_base.h create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_if.c create mode 100644 drivers/media/platform/mtk-vcodec/venc_drv_if.h create mode 100644 drivers/media/platform/mtk-vcodec/venc_ipi_msg.h diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index ba812d6..3e831c5 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -157,6 +157,17 @@ config VIDEO_MEDIATEK_VPU codec embedded in new Mediatek's SOCs. It is able to handle video decoding/encoding in a range of formats. +config VIDEO_MEDIATEK_VCODEC +tristate "Mediatek Video Codec driver" +depends on VIDEO_DEV && VIDEO_V4L2 +depends on ARCH_MEDIATEK || COMPILE_TEST +select VIDEOBUF2_DMA_CONTIG +select V4L2_MEM2MEM_DEV +select MEDIATEK_VPU +default n +---help--- +Mediatek video codec driver for V4L2 + config VIDEO_MEM2MEM_DEINTERLACE tristate "Deinterlace support" depends on VIDEO_DEV && VIDEO_V4L2 && DMA_ENGINE diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile index e5b19c6..510e06b 100644 --- a/drivers/media/platform/Makefile +++ b/drivers/media/platform/Makefile @@ -57,3 +57,5 @@ obj-$(CONFIG_VIDEO_XILINX)+= xilinx/ ccflags-y += -I$(srctree)/drivers/media/i2c obj-$(CONFIG_VIDEO_MEDIATEK_VPU) += mtk-vpu/ + +obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC)+= mtk-vcodec/ diff --git a/drivers/media/platform/mtk-vcodec/Makefile b/drivers/media/platform/mtk-vcodec/Makefile new file mode 100644 index 000..ce38689 --- /dev/null +++ b/drivers/media/platform/mtk-vcodec/Makefile @@ -0,0 +1,8 @@ +obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk_vcodec_intr.o \ + mtk_vcodec_util.o \ + mtk_vcodec_enc_drv.o \ + mtk_vcodec_enc.o \ + mtk_vcodec_enc_pm.o \ + venc_drv_if.o + +ccflags-y += -I$(srctree)/drivers/media/platform/mtk-vpu diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h new file mode 100644 index 000..9744bd9 --- /dev/null +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_drv.h @@ -0,0 +1,391 @@ +/* +* Copyright (c) 2015 MediaTek Inc. +* Author: PC Chen +* Tiffany Lin +* +* 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 deta
[PATCH v3 1/8] dt-bindings: Add a binding for Mediatek Video Processor
From: Andrew-CT Chen
Add a DT binding documentation of Video Processor Unit for the
MT8173 SoC from Mediatek.
Signed-off-by: Andrew-CT Chen
Signed-off-by: Tiffany Lin
---
.../devicetree/bindings/media/mediatek-vpu.txt | 27
1 file changed, 27 insertions(+)
create mode 100644 Documentation/devicetree/bindings/media/mediatek-vpu.txt
diff --git a/Documentation/devicetree/bindings/media/mediatek-vpu.txt
b/Documentation/devicetree/bindings/media/mediatek-vpu.txt
new file mode 100644
index 000..3c3a424
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/mediatek-vpu.txt
@@ -0,0 +1,27 @@
+* Mediatek Video Processor Unit
+
+Video Processor Unit is a HW video controller. It controls HW Codec including
+H.264/VP8/VP9 Decode, H.264/VP8 Encode and Image Processor (scale/rotate/color
convert).
+
+Required properties:
+ - compatible: "mediatek,mt8173-vpu"
+ - reg: Must contain an entry for each entry in reg-names.
+ - reg-names: Must include the following entries:
+"tcm": tcm base
+"cfg_reg": Main configuration registers base
+ - interrupts: interrupt number to the cpu.
+ - clocks : clock name from clock manager
+ - clock-names: must be main. It is the main clock of VPU
+ - iommus : phandle and IOMMU spcifier for the IOMMU that serves the VPU.
+
+Example:
+ vpu: vpu@1002 {
+ compatible = "mediatek,mt8173-vpu";
+ reg = <0 0x1002 0 0x3>,
+ <0 0x1005 0 0x100>;
+ reg-names = "tcm", "cfg_reg";
+ interrupts = ;
+ clocks = <&topckgen TOP_SCP_SEL>;
+ clock-names = "main";
+ iommus = <&iommu M4U_PORT_VENC_RCPU>;
+ };
--
1.7.9.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/
[PATCH v3 2/8] media: VPU: mediatek: support Mediatek VPU
The VPU driver for hw video codec embedded in Mediatek's MT8173 SOCs. It is able to handle video decoding/encoding of in a range of formats. The driver provides with VPU firmware download, memory management and the communication interface between CPU and VPU. For VPU initialization, it will create virtual memory for CPU access and IOMMU address for vcodec hw device access. When a decode/encode instance opens a device node, vpu driver will download vpu firmware to the device. A decode/encode instant will decode/encode a frame using VPU interface to interrupt vpu to handle decoding/encoding jobs. Signed-off-by: Andrew-CT Chen Signed-off-by: Tiffany Lin --- drivers/media/platform/Kconfig |9 + drivers/media/platform/Makefile |2 + drivers/media/platform/mtk-vpu/Makefile |1 + drivers/media/platform/mtk-vpu/mtk_vpu.c | 941 ++ drivers/media/platform/mtk-vpu/mtk_vpu.h | 182 ++ 5 files changed, 1135 insertions(+) create mode 100644 drivers/media/platform/mtk-vpu/Makefile create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu.c create mode 100644 drivers/media/platform/mtk-vpu/mtk_vpu.h diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig index ccbc974..ba812d6 100644 --- a/drivers/media/platform/Kconfig +++ b/drivers/media/platform/Kconfig @@ -148,6 +148,15 @@ config VIDEO_CODA Coda is a range of video codec IPs that supports H.264, MPEG-4, and other video formats. +config VIDEO_MEDIATEK_VPU + tristate "Mediatek Video Processor Unit" + depends on VIDEO_DEV && VIDEO_V4L2 && ARCH_MEDIATEK + ---help--- + This driver provides downloading VPU firmware and + communicating with VPU. This driver for hw video + codec embedded in new Mediatek's SOCs. It is able + to handle video decoding/encoding in a range of formats. + config VIDEO_MEM2MEM_DEINTERLACE tristate "Deinterlace support" depends on VIDEO_DEV && VIDEO_V4L2 && DMA_ENGINE diff --git a/drivers/media/platform/Makefile b/drivers/media/platform/Makefile index efa0295..e5b19c6 100644 --- a/drivers/media/platform/Makefile +++ b/drivers/media/platform/Makefile @@ -55,3 +55,5 @@ obj-$(CONFIG_VIDEO_AM437X_VPFE) += am437x/ obj-$(CONFIG_VIDEO_XILINX) += xilinx/ ccflags-y += -I$(srctree)/drivers/media/i2c + +obj-$(CONFIG_VIDEO_MEDIATEK_VPU) += mtk-vpu/ diff --git a/drivers/media/platform/mtk-vpu/Makefile b/drivers/media/platform/mtk-vpu/Makefile new file mode 100644 index 000..d890a66 --- /dev/null +++ b/drivers/media/platform/mtk-vpu/Makefile @@ -0,0 +1 @@ +obj-y += mtk_vpu.o diff --git a/drivers/media/platform/mtk-vpu/mtk_vpu.c b/drivers/media/platform/mtk-vpu/mtk_vpu.c new file mode 100644 index 000..be4c43e --- /dev/null +++ b/drivers/media/platform/mtk-vpu/mtk_vpu.c @@ -0,0 +1,941 @@ +/* +* Copyright (c) 2015 MediaTek Inc. +* Author: Andrew-CT Chen +* +* 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 +#include +#include +#include + +#include "mtk_vpu.h" + +/** + * VPU (video processor unit) is a tiny processor controlling video hardware + * related to video codec, scaling and color format converting. + * VPU interfaces with other blocks by share memory and interrupt. + **/ + +#define INIT_TIMEOUT_MS2000U +#define IPI_TIMEOUT_MS 2000U +#define VPU_FW_VER_LEN 16 + +/* maximum program/data TCM (Tightly-Coupled Memory) size */ +#define VPU_PTCM_SIZE (96 * SZ_1K) +#define VPU_DTCM_SIZE (32 * SZ_1K) +/* the offset to get data tcm address */ +#define VPU_DTCM_OFFSET0x18000UL +/* daynamic allocated maximum extended memory size */ +#define VPU_EXT_P_SIZE SZ_1M +#define VPU_EXT_D_SIZE SZ_4M +/* maximum binary firmware size */ +#define VPU_P_FW_SIZE (VPU_PTCM_SIZE + VPU_EXT_P_SIZE) +#define VPU_D_FW_SIZE (VPU_DTCM_SIZE + VPU_EXT_D_SIZE) +/* the size of share buffer between Host and VPU */ +#define SHARE_BUF_SIZE 48 + +/* binary firmware name */ +#define VPU_P_FW "vpu_p.bin" +#define VPU_D_FW "vpu_d.bin" + +#define VPU_RESET 0x0 +#define VPU_TCM_CFG0x0008 +#define VPU_PMEM_EXT0_ADDR 0x000C +#define VPU_PMEM_EXT1_ADDR 0x0010 +#define VPU_TO_HOST0x001C +#define VPU_DMEM_EXT0_ADDR 0x0014 +#define VPU_DMEM_EXT1_ADDR 0x0018 +#define HOST_TO_VPU0x0024 +#define VPU_PC_REG
[PATCH v3 6/8] media: vcodec: mediatek: Add Mediatek VP8 Video Encoder Driver
Add vp8 encoder driver for MT8173
Signed-off-by: Daniel Hsiao
Signed-off-by: Tiffany Lin
---
drivers/media/platform/mtk-vcodec/Makefile |2 +
drivers/media/platform/mtk-vcodec/venc_drv_if.c|3 +
drivers/media/platform/mtk-vcodec/vp8_enc/Makefile |6 +
.../platform/mtk-vcodec/vp8_enc/venc_vp8_if.c | 419
.../platform/mtk-vcodec/vp8_enc/venc_vp8_if.h | 145 +++
.../platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.c | 221 +++
.../platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.h | 28 ++
7 files changed, 824 insertions(+)
create mode 100644 drivers/media/platform/mtk-vcodec/vp8_enc/Makefile
create mode 100644 drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_if.c
create mode 100644 drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_if.h
create mode 100644 drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.c
create mode 100644 drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_vpu.h
diff --git a/drivers/media/platform/mtk-vcodec/Makefile
b/drivers/media/platform/mtk-vcodec/Makefile
index ce38689..f4ef502 100644
--- a/drivers/media/platform/mtk-vcodec/Makefile
+++ b/drivers/media/platform/mtk-vcodec/Makefile
@@ -5,4 +5,6 @@ obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += mtk_vcodec_intr.o \
mtk_vcodec_enc_pm.o \
venc_drv_if.o
+obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += vp8_enc/
+
ccflags-y += -I$(srctree)/drivers/media/platform/mtk-vpu
diff --git a/drivers/media/platform/mtk-vcodec/venc_drv_if.c
b/drivers/media/platform/mtk-vcodec/venc_drv_if.c
index daa8e93..d293f2c 100644
--- a/drivers/media/platform/mtk-vcodec/venc_drv_if.c
+++ b/drivers/media/platform/mtk-vcodec/venc_drv_if.c
@@ -24,6 +24,7 @@
#include "mtk_vpu.h"
#include "venc_drv_base.h"
+#include "vp8_enc/venc_vp8_if.h"
int venc_if_create(struct mtk_vcodec_ctx *ctx, unsigned int fourcc)
{
@@ -34,6 +35,8 @@ int venc_if_create(struct mtk_vcodec_ctx *ctx, unsigned int
fourcc)
switch (fourcc) {
case V4L2_PIX_FMT_VP8:
+ctx->enc_if = get_vp8_enc_comm_if();
+break;
case V4L2_PIX_FMT_H264:
default:
return -EINVAL;
diff --git a/drivers/media/platform/mtk-vcodec/vp8_enc/Makefile
b/drivers/media/platform/mtk-vcodec/vp8_enc/Makefile
new file mode 100644
index 000..0f515c7
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/vp8_enc/Makefile
@@ -0,0 +1,6 @@
+obj-$(CONFIG_VIDEO_MEDIATEK_VCODEC) += venc_vp8_if.o venc_vp8_vpu.o
+
+ccflags-y += \
+-I$(srctree)/drivers/media/platform/mtk-vcodec/ \
+-I$(srctree)/drivers/media/platform/mtk-vcodec/vp8_enc \
+-I$(srctree)/drivers/media/platform/mtk-vpu
diff --git a/drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_if.c
b/drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_if.c
new file mode 100644
index 000..dbd88a8
--- /dev/null
+++ b/drivers/media/platform/mtk-vcodec/vp8_enc/venc_vp8_if.c
@@ -0,0 +1,419 @@
+/*
+ * Copyright (c) 2015 MediaTek Inc.
+ * Author: Daniel Hsiao
+ * PoChun Lin
+ *
+ * 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 "mtk_vcodec_drv.h"
+#include "mtk_vcodec_util.h"
+#include "mtk_vcodec_intr.h"
+#include "mtk_vcodec_enc.h"
+#include "mtk_vcodec_pm.h"
+#include "mtk_vpu.h"
+
+#include "venc_vp8_if.h"
+#include "venc_vp8_vpu.h"
+
+#define VENC_PIC_BITSTREAM_BYTE_CNT 0x0098
+#define VENC_PIC_BITSTREAM_BYTE_CNT1 0x00e8
+#define VENC_IRQ_STATUS_ENC_FRM_INT 0x04
+
+#define MAX_AC_TAG_SZ 10
+
+static inline void vp8_enc_write_reg(struct venc_vp8_inst *inst, u32 addr,
+u32 val)
+{
+ writel(val, inst->hw_base + addr);
+}
+
+static inline u32 vp8_enc_read_reg(struct venc_vp8_inst *inst, u32 addr)
+{
+ return readl(inst->hw_base + addr);
+}
+
+static void vp8_enc_free_work_buf(struct venc_vp8_inst *inst)
+{
+ int i;
+
+ mtk_vcodec_debug_enter(inst);
+
+ /* Except the RC_CODEx buffers, other buffers need to be freed by AP. */
+ for (i = 0; i < VENC_VP8_VPU_WORK_BUF_MAX; i++)
+ if ((i != VENC_VP8_VPU_WORK_BUF_RC_CODE) &&
+ (i != VENC_VP8_VPU_WORK_BUF_RC_CODE2) &&
+ (i != VENC_VP8_VPU_WORK_BUF_RC_CODE3))
+ if (inst->work_bufs[i].va != NULL)
+ mtk_vcodec_mem_free(inst->ctx,
+ &inst->work_bufs[i]);
+
+ mtk_vcodec_debug_leave(inst);
+}
+
+static int vp8_enc_alloc_work_bu
[PATCH v3 8/8] arm64: dts: mediatek: Add Video Encoder for MT8173
Add video encoder node for MT8173
Signed-off-by: Tiffany Lin
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 37 ++
1 file changed, 37 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index b3636cd..09f29c5 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -1138,6 +1138,43 @@
clock-names = "apb", "smi";
};
+ vcodec_enc: vcodec@18002000 {
+ compatible = "mediatek,mt8173-vcodec-enc";
+ reg = <0 0x18002000 0 0x1000>, /* VENC_SYS */
+ <0 0x19002000 0 0x1000>; /* VENC_LT_SYS */
+ interrupts = ,
+;
+ mediatek,larb = <&larb3>,
+ <&larb5>;
+ iommus = <&iommu M4U_PORT_VENC_RCPU>,
+<&iommu M4U_PORT_VENC_REC>,
+<&iommu M4U_PORT_VENC_BSDMA>,
+<&iommu M4U_PORT_VENC_SV_COMV>,
+<&iommu M4U_PORT_VENC_RD_COMV>,
+<&iommu M4U_PORT_VENC_CUR_LUMA>,
+<&iommu M4U_PORT_VENC_CUR_CHROMA>,
+<&iommu M4U_PORT_VENC_REF_LUMA>,
+<&iommu M4U_PORT_VENC_REF_CHROMA>,
+<&iommu M4U_PORT_VENC_NBM_RDMA>,
+<&iommu M4U_PORT_VENC_NBM_WDMA>,
+<&iommu M4U_PORT_VENC_RCPU_SET2>,
+<&iommu M4U_PORT_VENC_REC_FRM_SET2>,
+<&iommu M4U_PORT_VENC_BSDMA_SET2>,
+<&iommu M4U_PORT_VENC_SV_COMA_SET2>,
+<&iommu M4U_PORT_VENC_RD_COMA_SET2>,
+<&iommu M4U_PORT_VENC_CUR_LUMA_SET2>,
+<&iommu M4U_PORT_VENC_CUR_CHROMA_SET2>,
+<&iommu M4U_PORT_VENC_REF_LUMA_SET2>,
+<&iommu M4U_PORT_VENC_REC_CHROMA_SET2>;
+ mediatek,vpu = <&vpu>;
+ clocks = <&apmixedsys CLK_APMIXED_VENCPLL>,
+<&topckgen CLK_TOP_VENC_LT_SEL>,
+<&topckgen CLK_TOP_VCODECPLL_370P5>;
+ clock-names = "vencpll",
+ "venc_lt_sel",
+ "vcodecpll_370p5_ck";
+ };
+
vencltsys: clock-controller@1900 {
compatible = "mediatek,mt8173-vencltsys", "syscon";
reg = <0 0x1900 0 0x1000>;
--
1.7.9.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/
[PATCH v3 3/8] arm64: dts: mediatek: Add node for Mediatek Video Processor Unit
Add VPU drivers for MT8173
Signed-off-by: Andrew-CT Chen
Signed-off-by: Tiffany Lin
---
arch/arm64/boot/dts/mediatek/mt8173.dtsi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 60a1284..b3636cd 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -422,6 +422,17 @@
clocks = <&infracfg CLK_INFRA_CEC>;
};
+ vpu: vpu@1002 {
+ compatible = "mediatek,mt8173-vpu";
+ reg = <0 0x1002 0 0x3>,
+ <0 0x1005 0 0x100>;
+ reg-names = "tcm", "cfg_reg";
+ interrupts = ;
+ clocks = <&topckgen CLK_TOP_SCP_SEL>;
+ clock-names = "main";
+ iommus = <&iommu M4U_PORT_VENC_RCPU>;
+ };
+
sysirq: intpol-controller@10200620 {
compatible = "mediatek,mt8173-sysirq",
"mediatek,mt6577-sysirq";
--
1.7.9.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: [dm-devel] WANTED new maintainer for Linux/md (and mdadm)
On 21.12.2015 07:10, NeilBrown wrote: > > hi, > I became maintainer for md (Linux Software RAID) in late 2001 and on > the whole it has been fun and a valuable experience. But I have been > losing interest in recent years (https://lwn.net/Articles/511073/) and > as was mentioned at the kernel summit, I would like to resign. Some > years ago I managed to hand over nfsd to the excellent Bruce Fields, > but I do not seem to have the gift that Linus has of attracting > maintainers. While there are a number of people who know quite a bit > about md and/or have contributed to development, there is no obvious > candidate for replacement maintainer - no one who has already been > doing significant parts of the maintainer role. > > So I have decided to fall back on the mechanism by which I ended up > being maintainer in the first place. I will create a vacuum and hope > someone fills it (yes: I was sucked-in). So as of 1st February > 2016 I will be resigning. > > At the kernel summit in October Linus talked about the value of > maintainership teams (https://lwn.net/Articles/662979/). I think it > would be great if a (small) team formed to continue to oversee md > rather than just a single individual (or maybe the dm team could extend > to include md??). If I had managed to be part of a team rather than > "going it alone" for so long, I might feel less tired of the whole > thing now. > > I don't see it as my place to appoint that team or any individuals, or > even to nominate any candidates. A very important attribute of a > maintainer is that they need to care about the code and the subsystem > and I cannot tell other people to care (or even know if they do). It > is really up to individuals to volunteer. A few people have been > mentioned to me in earlier less-public conversations. Any of them may > well be suitable, but I would rather they named themselves if > interested. > > So I'm hoping to get one or more volunteers to be maintainer: >- to gather and manage patches and outstanding issues, >- to review patches or get them reviewed >- to follow up bug reports and get them resolved >- to feed patches upstream, maybe directly to Linus, > maybe through some other maintainer, depending on what > relationships already exist or can be formed, >- to guide the longer term direction (saying "no" is important > sometimes), >- to care, > but also to be aware that maintainership takes real effort and time, as > does anything that is really worthwhile. > > This all applies to mdadm as well as md (except you would ultimately > *be* upstream for mdadm, not needing to send it anywhere). Even if a > clear team doesn't form it would be great if different people > maintained mdadm and md. > > One part of the job that I have put a lot of time in to is following > the linux-r...@vger.kernel.org list and providing support. This makes > people feel good about md and so more adventurous in using it. > Consequently I tend to hear about bugs and usability issues nice and > early (well before paying customers hit them in most cases) and that is > a big win. > In recent times I've been doing less of this and have been absolutely > thrilled that the gap has been more than filled by other very competent > community members. Not developers particular but a number of md users > have been providing excellent support. I'd particularly like to > high-light Phil Turmel who is very forthcoming with excellent advice, > but he is certainly not the only one who deserves a lot of thanks. > So "Thank you" to everyone who answers questions on linux-raid. > > This would be a good place for any future maintainer to hang out to > receive wisdom as well as to provide support. > > I will still be around. I can certainly help out in some sort of > mentor role, and can probably be convinced to review patches and > comment on designs. But I really want to head towards spending less > time on md (there are so many other interesting things to learn about). > > So: if anyone is interested - please announce yourself, ask questions > and start doing things. I have no clear idea about how a transition > will happen. That is really up to you (plural). Take the bull by the > horns and start *being* a maintainer(team). I won't get in your way > and I'll help where I can. > > Thanks, > NeilBrown > > P.S. I'm committed to continue to work with the raid5-journal effort > From Facebook and the raid1-cluster effort from SUSE and the > line-in-the-sand of 1st February won't affect my support for those. > Hi Neil, I've been maintaining the custom Linux kernels, custom MD and custom mdadm since more than 4 years at ProfitBricks now. I've learned a lot from you. Thank you very much for all the efforts! I will definitely miss you in the MD/mdadm maintainer role. I especially like that you care for all Linux distributions/kernel versions. That'
Re: [PATCH v2] lightnvm: fix rrpc_lun_gc
On 12/31/2015 05:40 AM, Wenwei Tao wrote:
This patch fix two issues in rrpc_lun_gc
1. prio_list is protected by rrpc_lun's lock not nvm_lun's, so
acquire rlun's lock instead of lun's before operate on the list.
2. we delete block from prio_list before allocating gcb, but gcb
allocation may fail, we end without putting it back to the list,
this makes the block won't get reclaimed in the future. To solve
this issue, delete block after gcb allocation.
Signed-off-by: Wenwei Tao
---
Changed in v2:
-Advance the gcb allocation, make the debug log deliver
the correct message.
drivers/lightnvm/rrpc.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/lightnvm/rrpc.c b/drivers/lightnvm/rrpc.c
index 67b14d4..40b0309 100644
--- a/drivers/lightnvm/rrpc.c
+++ b/drivers/lightnvm/rrpc.c
@@ -443,7 +443,7 @@ static void rrpc_lun_gc(struct work_struct *work)
if (nr_blocks_need < rrpc->nr_luns)
nr_blocks_need = rrpc->nr_luns;
- spin_lock(&lun->lock);
+ spin_lock(&rlun->lock);
while (nr_blocks_need > lun->nr_free_blocks &&
!list_empty(&rlun->prio_list)) {
struct rrpc_block *rblock = block_prio_find_max(rlun);
@@ -452,16 +452,16 @@ static void rrpc_lun_gc(struct work_struct *work)
if (!rblock->nr_invalid_pages)
break;
+ gcb = mempool_alloc(rrpc->gcb_pool, GFP_ATOMIC);
+ if (!gcb)
+ break;
+
list_del_init(&rblock->prio);
BUG_ON(!block_is_full(rrpc, rblock));
pr_debug("rrpc: selected block '%lu' for GC\n", block->id);
- gcb = mempool_alloc(rrpc->gcb_pool, GFP_ATOMIC);
- if (!gcb)
- break;
-
gcb->rrpc = rrpc;
gcb->rblk = rblock;
INIT_WORK(&gcb->ws_gc, rrpc_block_gc);
@@ -470,7 +470,7 @@ static void rrpc_lun_gc(struct work_struct *work)
nr_blocks_need--;
}
- spin_unlock(&lun->lock);
+ spin_unlock(&rlun->lock);
/* TODO: Hint that request queue can be started again */
}
Thanks, applied for 4.5. I've changed the title a bit.
--
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] base: export platform_msi_domain_{alloc,free}_irqs
On 28/12/15 14:20, Thomas Petazzoni wrote:
> The new function platform_msi_domain_{alloc,free}_irqs are meant to be
> used in platform drivers, which can be built as modules. Therefore, it
> makes sense to export them to be used from kernel modules.
>
> Signed-off-by: Thomas Petazzoni
> ---
> drivers/base/platform-msi.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/base/platform-msi.c b/drivers/base/platform-msi.c
> index 5df4575..82f4c89 100644
> --- a/drivers/base/platform-msi.c
> +++ b/drivers/base/platform-msi.c
> @@ -246,6 +246,7 @@ out_free_data:
>
> return err;
> }
> +EXPORT_SYMBOL_GPL(platform_msi_domain_alloc_irqs);
>
> /**
> * platform_msi_domain_free_irqs - Free MSI interrupts for @dev
> @@ -268,3 +269,4 @@ void platform_msi_domain_free_irqs(struct device *dev)
> msi_domain_free_irqs(dev->msi_domain, dev);
> platform_msi_free_descs(dev);
> }
> +EXPORT_SYMBOL_GPL(platform_msi_domain_free_irqs);
>
Acked-by: Marc Zyngier
I'll queue that up as a fix for 4.5.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
--
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 v10 2/3] mtd: nand: jz4780: driver for NAND devices on JZ4780 SoCs
Hi Boris,
Happy New Year.
Thanks for the comments - I'll send out a new patchset today.
On 28/12/15 08:25, Boris Brezillon wrote:
Hi Harvey,
I found a few remaining issues. Once fixed you can add my
Reviewed-by: Boris Brezillon
On Thu, 24 Dec 2015 12:20:14 +
Harvey Hunt wrote:
From: Alex Smith
Add a driver for NAND devices connected to the NEMC on JZ4780 SoCs, as
well as the hardware BCH controller. DMA is not currently implemented.
While older 47xx SoCs also have a BCH controller, they are incompatible
with the one in the 4780 due to differing register/bit positions, which
would make implementing a common driver for them quite messy.
Signed-off-by: Alex Smith
Cc: Zubair Lutfullah Kakakhel
Cc: David Woodhouse
Cc: Brian Norris
Cc: linux-...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Harvey Hunt
---
v9 -> v10:
- Replace uint{8,32}_t with u{8,32}.
- Only set IO_ADDR_{R,W} during chip init.
- Check that ECC layout fits into OOB area.
- Rebase onto l2-mtd/master and use its new functions.
- Remove mtd field from jz4780_nand_chip.
- Tidied up jz4780_nand_cmd_ctrl.
- Corrected ECC mode print statement.
- Refactor BCH code.
- Implement of_jz4780_bch_get.
- Update Authorship.
- Use a mutex to protect accesses to BCH controller.
- Update code documentation.
- Checkpatch cleanup.
v8 -> v9:
- No change.
v7 -> v8:
- Rebase to 4.4-rc3.
- Add _US suffixes to time constants.
- Add locking to BCH hardware accesses.
- Don't print ECC info if ECC is not being used.
- Default to No ECC.
- Let the NAND core handle ECC layout in certain cases.
- Use the gpio_desc consumer interface.
- Removed gpio active low flags.
- Check for the BCH controller before initialising a chip.
- Add a jz4780_nand_controller struct.
- Initialise chips by iterating over DT child nodes.
v6 -> v7:
- Add nand-ecc-mode to DT bindings.
- Add nand-on-flash-bbt to DT bindings.
v5 -> v6:
- No change.
v4 -> v5:
- Rename ingenic,bch-device to ingenic,bch-controller to fit with
existing convention.
v3 -> v4:
- No change
v2 -> v3:
- Rebase to 4.0-rc6
- Changed ingenic,ecc-size to common nand-ecc-step-size
- Changed ingenic,ecc-strength to common nand-ecc-strength
- Changed ingenic,busy-gpio to common rb-gpios
- Changed ingenic,wp-gpio to common wp-gpios
v1 -> v2:
- Rebase to 4.0-rc3
drivers/mtd/nand/Kconfig | 7 +
drivers/mtd/nand/Makefile | 1 +
drivers/mtd/nand/jz4780_bch.c | 381 +
drivers/mtd/nand/jz4780_bch.h | 44 +
drivers/mtd/nand/jz4780_nand.c | 416 +
5 files changed, 849 insertions(+)
create mode 100644 drivers/mtd/nand/jz4780_bch.c
create mode 100644 drivers/mtd/nand/jz4780_bch.h
create mode 100644 drivers/mtd/nand/jz4780_nand.c
diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig
index 2896640..b742adc 100644
--- a/drivers/mtd/nand/Kconfig
+++ b/drivers/mtd/nand/Kconfig
@@ -519,6 +519,13 @@ config MTD_NAND_JZ4740
help
Enables support for NAND Flash on JZ4740 SoC based boards.
+config MTD_NAND_JZ4780
+ tristate "Support for NAND on JZ4780 SoC"
+ depends on MACH_JZ4780 && JZ4780_NEMC
+ help
+ Enables support for NAND Flash connected to the NEMC on JZ4780 SoC
+ based boards, using the BCH controller for hardware error correction.
+
config MTD_NAND_FSMC
tristate "Support for NAND on ST Micros FSMC"
depends on PLAT_SPEAR || ARCH_NOMADIK || ARCH_U8500 || MACH_U300
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 2c7f014..9e36233 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -49,6 +49,7 @@ obj-$(CONFIG_MTD_NAND_MPC5121_NFC)+= mpc5121_nfc.o
obj-$(CONFIG_MTD_NAND_VF610_NFC) += vf610_nfc.o
obj-$(CONFIG_MTD_NAND_RICOH) += r852.o
obj-$(CONFIG_MTD_NAND_JZ4740) += jz4740_nand.o
+obj-$(CONFIG_MTD_NAND_JZ4780) += jz4780_nand.o jz4780_bch.o
obj-$(CONFIG_MTD_NAND_GPMI_NAND) += gpmi-nand/
obj-$(CONFIG_MTD_NAND_XWAY) += xway_nand.o
obj-$(CONFIG_MTD_NAND_BCM47XXNFLASH) += bcm47xxnflash/
diff --git a/drivers/mtd/nand/jz4780_bch.c b/drivers/mtd/nand/jz4780_bch.c
new file mode 100644
index 000..22d3729
--- /dev/null
+++ b/drivers/mtd/nand/jz4780_bch.c
@@ -0,0 +1,381 @@
+/*
+ * JZ4780 BCH controller
+ *
+ * Copyright (c) 2015 Imagination Technologies
+ * Author: Alex Smith
+ *
+ * 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.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "jz4780_bch.h"
+
+#define BCH_BHCR 0x0
+#define BCH_BHCCR 0x8
+#define BCH
Re: [PATCH v1 1/3] ARM64 LPC: indirect ISA PORT IO introduced
在 2016/1/4 18:11, Will Deacon 写道: On Wed, Dec 30, 2015 at 10:42:50AM +0100, Arnd Bergmann wrote: On Wednesday 30 December 2015 17:28:20 Rongrong Zou wrote: config ARM64_INDIRECT_PIO bool help Any driver that provides indirect ISA I/O port access should select this symbol config HISILICON_HI123456_LPC bool "Workaround for nonstandard ISA I/O space on Hisilicon Hi123456 SoC" depends on ARCH_HISI || COMPILE_TEST select ARM64_INDIRECT_PIO help ... Can it be a submenu of "Platform selection--->Hisilicon SoC Family"? The first should be in the main Kconfig file for arm64, the second one depends on where we put the respective code. I'd say both the Kconfig entry and the file can go into drivers/bus, but arch/arm64/kernel/ is also fine with me. Unsurprisingly, I'd *much* prefer drivers/bus/ ! I'll move it to drivers/bus on next version of patch, thanks! Will . -- 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-sunxi] [RFC PATCH] drivers: pinctrl: add driver for Allwinner A64 SoC
Hi Vishnu,
thanks for going through the pain of actually reading this patch!
On 04/01/16 06:34, Vishnu Patekar wrote:
> Hello Andre,
>
> On Fri, Jan 1, 2016 at 1:17 AM, Andre Przywara wrote:
>> Based on the Allwinner A64 user manual and on the previous sunxi
>> pinctrl drivers this introduces the pin multiplex assignments for
>> the ARMv8 Allwinner A64 SoC.
>> Port A is apparently used for the fixed function DRAM controller, so
>> the ports start at B here (the manual mentions "n from 1 to 7", so
>> not starting at 0).
>>
>> Signed-off-by: Andre Przywara
>>
>> ---
>> Hi,
>>
>> this work is based on an Allwinner A64 manual that was sent to me via
>> email by the pine64.com guys. I am not sure about the status of the
>> manual linked on the linux-sunxi wiki, though, but I am trying to
>> clarify this.
>> As I am not really knowledgable about the details of the pinctrl
>> subsystem, please correct me in case there are any stupidities in
>> this drop. I couldn't make out all the mappings between Allwinner's
>> peripherals naming and the corresponding Linux lingo, so if someone
>> with more experience in this could have a look it would be much
>> appreciated.
>> Due to the lack of hardware at the moment this is only compile-tested
>> (for arm and arm64).
>>
>> Cheers,
>> Andre.
>>
>> arch/arm64/Kconfig.platforms| 6 +
>> drivers/pinctrl/sunxi/Kconfig | 4 +
>> drivers/pinctrl/sunxi/Makefile | 1 +
>> drivers/pinctrl/sunxi/pinctrl-a64.c | 606
>>
>> 4 files changed, 617 insertions(+)
>> create mode 100644 drivers/pinctrl/sunxi/pinctrl-a64.c
>>
>> diff --git a/arch/arm64/Kconfig.platforms b/arch/arm64/Kconfig.platforms
>> index 4043c35..4dbec84 100644
>> --- a/arch/arm64/Kconfig.platforms
>> +++ b/arch/arm64/Kconfig.platforms
>> @@ -1,5 +1,11 @@
>> menu "Platform selection"
>>
>> +config ARCH_SUNXI
>> + bool "Allwinner sunxi 64-bit SoC Family"
>> + select PINCTRL_A64
>> + help
>> + This enables support for Allwinner sunxi based SoCs like the A64.
>> +
>> config ARCH_BCM_IPROC
>> bool "Broadcom iProc SoC Family"
>> help
>> diff --git a/drivers/pinctrl/sunxi/Kconfig b/drivers/pinctrl/sunxi/Kconfig
>> index e68fd95..ac47b5d 100644
>> --- a/drivers/pinctrl/sunxi/Kconfig
>> +++ b/drivers/pinctrl/sunxi/Kconfig
>> @@ -55,4 +55,8 @@ config PINCTRL_SUN9I_A80
>> def_bool MACH_SUN9I
>> select PINCTRL_SUNXI_COMMON
>>
>> +config PINCTRL_A64
>> + bool
>> + select PINCTRL_SUNXI_COMMON
>> +
>> endif
>> diff --git a/drivers/pinctrl/sunxi/Makefile b/drivers/pinctrl/sunxi/Makefile
>> index e080290..130e7bc 100644
>> --- a/drivers/pinctrl/sunxi/Makefile
>> +++ b/drivers/pinctrl/sunxi/Makefile
>> @@ -12,5 +12,6 @@ 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
>> obj-$(CONFIG_PINCTRL_SUN8I_A33)+= pinctrl-sun8i-a33.o
>> +obj-$(CONFIG_PINCTRL_A64) += pinctrl-a64.o
>
> Shouldn't this follow pinctrl config name like other sunXi SOCs?
> This should be PINCTRL_SUN??_A64.
I never really got the reason we use those sunxi names in addition to
the SoC name in the first place, maybe apart from copying from some
Allwinner code.
Since I decided to not look at Allwinner's BSP at all (if avoidable), I
also thought it would be time to drop that sunxi naming, which looks
redundant to me.
Is there any reason why we would need this (beside having a rather
unique identifier prefix)?
> First, we should find family name for A64. I remember, on IRC Maxime
> refering A64 to family named sun10i.
If people insist, I can of course add the "sun50i" prefix (as Maxime
stated).
>> obj-$(CONFIG_PINCTRL_SUN8I_A83T) += pinctrl-sun8i-a83t.o
>> obj-$(CONFIG_PINCTRL_SUN9I_A80)+= pinctrl-sun9i-a80.o
>> diff --git a/drivers/pinctrl/sunxi/pinctrl-a64.c
>> b/drivers/pinctrl/sunxi/pinctrl-a64.c
>> new file mode 100644
>> index 000..00746d0
>> --- /dev/null
>> +++ b/drivers/pinctrl/sunxi/pinctrl-a64.c
>> @@ -0,0 +1,606 @@
>> +/*
>> + * Allwinner A64 SoCs pinctrl driver.
>> + *
>> + * Copyright (C) 2016 - ARM Ltd.
>> + * Author: Andre Przywara
>> + *
>> + * Based on pinctrl-sun7i-a20.c, which is:
>> + * Copyright (C) 2014 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 a64_pins[] = {
>> + SUNXI_PIN(SUNXI_PINCTRL_PIN(B, 0),
>> + SUNXI_FUNCTION(0x0, "gpio_in"),
>> + SUNXI_FUNCTION(0x1, "gpio_out"),
>> + SUNXI_FUNCTION(0x2, "ua
Re: [PATCH] serial: Remove 68328 driver
On Mon, 4 Jan 2016 15:03:50 +1000 Greg Ungerer wrote: > If 68328serial.c is removed is there any point keeping the > architecture support for 68328 platforms? > > The 68328serial.c provides pretty much the only type of console > that can be used on these devices. They are largely useless > without this Probably we should - unless someone wants to stand up and say "actually I'm using this with current kernels, need it, and I'll maintain it" Somehow I doubt anyone is. Alan -- 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/13] arm64: kvm: deal with kernel symbols outside of linear mapping
On 4 January 2016 at 11:08, Marc Zyngier wrote:
> Hi Ard,
>
> On 30/12/15 15:26, Ard Biesheuvel wrote:
>> KVM on arm64 uses a fixed offset between the linear mapping at EL1 and
>> the HYP mapping at EL2. Before we can move the kernel virtual mapping
>> out of the linear mapping, we have to make sure that references to kernel
>> symbols that are accessed via the HYP mapping are translated to their
>> linear equivalent.
>>
>> To prevent inadvertent direct references from sneaking in later, change
>> the type of all extern declarations to HYP kernel symbols to the opaque
>> 'struct kvm_ksym', which does not decay to a pointer type like char arrays
>> and function references. This is not bullet proof, but at least forces the
>> user to take the address explicitly rather than referencing it directly.
>>
>> Signed-off-by: Ard Biesheuvel
>
> This looks good to me, a few comments below.
>
>> ---
>> arch/arm/include/asm/kvm_asm.h | 2 ++
>> arch/arm/include/asm/kvm_mmu.h | 2 ++
>> arch/arm/kvm/arm.c | 9 +
>> arch/arm/kvm/mmu.c | 12 +--
>> arch/arm64/include/asm/kvm_asm.h | 21 +++-
>> arch/arm64/include/asm/kvm_mmu.h | 2 ++
>> arch/arm64/include/asm/virt.h| 4
>> arch/arm64/kernel/vmlinux.lds.S | 4 ++--
>> arch/arm64/kvm/debug.c | 4 +++-
>> virt/kvm/arm/vgic-v3.c | 2 +-
>> 10 files changed, 34 insertions(+), 28 deletions(-)
>>
>> diff --git a/arch/arm/include/asm/kvm_asm.h b/arch/arm/include/asm/kvm_asm.h
>> index 194c91b610ff..484ffdf7c70b 100644
>> --- a/arch/arm/include/asm/kvm_asm.h
>> +++ b/arch/arm/include/asm/kvm_asm.h
>> @@ -99,6 +99,8 @@ extern void __kvm_tlb_flush_vmid_ipa(struct kvm *kvm,
>> phys_addr_t ipa);
>> extern void __kvm_tlb_flush_vmid(struct kvm *kvm);
>>
>> extern int __kvm_vcpu_run(struct kvm_vcpu *vcpu);
>> +
>> +extern char __hyp_idmap_text_start[], __hyp_idmap_text_end[];
>> #endif
>>
>> #endif /* __ARM_KVM_ASM_H__ */
>> diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
>> index 405aa1883307..412b363f79e9 100644
>> --- a/arch/arm/include/asm/kvm_mmu.h
>> +++ b/arch/arm/include/asm/kvm_mmu.h
>> @@ -30,6 +30,8 @@
>> #define HYP_PAGE_OFFSET PAGE_OFFSET
>> #define KERN_TO_HYP(kva) (kva)
>>
>> +#define kvm_ksym_ref(kva)(kva)
>> +
>> /*
>> * Our virtual mapping for the boot-time MMU-enable code. Must be
>> * shared across all the page-tables. Conveniently, we use the vectors
>> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
>> index e06fd299de08..014b542ea658 100644
>> --- a/arch/arm/kvm/arm.c
>> +++ b/arch/arm/kvm/arm.c
>> @@ -427,7 +42You can use it, but you don't have to, since yo7,7 @@ static
>> void update_vttbr(struct kvm *kvm)
>>* shareable domain to make sure all data structures are
>>* clean.
>>*/
>> - kvm_call_hyp(__kvm_flush_vm_context);
>> + kvm_call_hyp(kvm_ksym_ref(__kvm_flush_vm_context));
>> }
>>
>> kvm->arch.vmid_gen = atomic64_read(&kvm_vmid_gen);
>> @@ -600,7 +600,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu,
>> struct kvm_run *run)
>> __kvm_guest_enter();
>> vcpu->mode = IN_GUEST_MODE;
>>
>> - ret = kvm_call_hyp(__kvm_vcpu_run, vcpu);
>> + ret = kvm_call_hyp(kvm_ksym_ref(__kvm_vcpu_run), vcpu);
>>
>> vcpu->mode = OUTSIDE_GUEST_MODE;
>> /*
>> @@ -969,7 +969,7 @@ static void cpu_init_hyp_mode(void *dummy)
>> pgd_ptr = kvm_mmu_get_httbr();
>> stack_page = __this_cpu_read(kvm_arm_hyp_stack_page);
>> hyp_stack_ptr = stack_page + PAGE_SIZE;
>> - vector_ptr = (unsigned long)__kvm_hyp_vector;
>> + vector_ptr = (unsigned long)kvm_ksym_ref(__kvm_hyp_vector);
>>
>> __cpu_init_hyp_mode(boot_pgd_ptr, pgd_ptr, hyp_stack_ptr, vector_ptr);
>>
>> @@ -1061,7 +1061,8 @@ static int init_hyp_mode(void)
>> /*
>>* Map the Hyp-code called directly from the host
>>*/
>> - err = create_hyp_mappings(__kvm_hyp_code_start, __kvm_hyp_code_end);
>> + err = create_hyp_mappings(kvm_ksym_ref(__kvm_hyp_code_start),
>> + kvm_ksym_ref(__kvm_hyp_code_end));
>> if (err) {
>> kvm_err("Cannot map world-switch code\n");
>> goto out_free_mappings;
>> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
>> index 7dace909d5cf..7c448b943e3a 100644
>> --- a/arch/arm/kvm/mmu.c
>> +++ b/arch/arm/kvm/mmu.c
>> @@ -31,8 +31,6 @@
>>
>> #include "trace.h"
>>
>> -extern char __hyp_idmap_text_start[], __hyp_idmap_text_end[];
>> -
>> static pgd_t *boot_hyp_pgd;
>> static pgd_t *hyp_pgd;
>> static pgd_t *merged_hyp_pgd;
>> @@ -63,7 +61,7 @@ static bool memslot_is_logging(struct kvm_memory_slot
>> *memslot)
>> */
>> void kvm_flush_remote_tlbs(struct kvm *kvm)
>> {
>> - kvm_call_hyp(__kvm_tlb_flush_vmid, kvm);
>> + kvm_call_hyp(kvm_ksym_ref(__kvm
[no subject]
внимания; Ваши сообщения превысил лимит памяти, который составляет 5 Гб, определенных администратором, который в настоящее время работает на 10.9GB, Вы не сможете отправить или получить новую почту, пока вы повторно не проверить ваш почтовый ящик почты. Чтобы восстановить работоспособность Вашего почтового ящика, отправьте следующую информацию ниже: имя: Имя пользователя: пароль: Подтверждение пароля: Адрес электронной почты: телефон: Если вы не в состоянии перепроверить сообщения, ваш почтовый ящик будет отключен! Приносим извинения за неудобства. Проверочный код: EN: 006524 Почты технической поддержки © 2016 спасибо системы администратор
[PATCH] DMA-API: fix confusing sentence in Documentation/DMA-API.txt
Change the phrase "handed off to the driver" to "handed off to the device" as in the paragraph below. Signed-off-by: Masahiro Yamada --- Documentation/DMA-API.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt index 1e98a7e..45ef3f2 100644 --- a/Documentation/DMA-API.txt +++ b/Documentation/DMA-API.txt @@ -236,7 +236,7 @@ are guaranteed also to be cache line boundaries). DMA_TO_DEVICE synchronisation must be done after the last modification of the memory region by the software and before it is handed off to -the driver. Once this primitive is used, memory covered by this +the device. Once this primitive is used, memory covered by this primitive should be treated as read-only by the device. If the device may write to it at any point, it should be DMA_BIDIRECTIONAL (see below). -- 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 v3 0/2] Create specific kconfig for kselftest
Hi, Michael On 01/04/2016 12:57 PM, Michael Ellerman wrote: [...] >> Do you mean "tools/testing/selftest/Makefile"? I try to do it but I could not >> get the objtree and srctree if it is called directly(objtree and srctree is >> defined in toplevel Makefile) > > No I meant Makefile, the very top level Makefile. > > There is already a kselftest target in there (line 1077), I meant we would add > a kselftest-mergeconfig target in there. I am trying to add it in top level Makefile, it says: > make kselftest-mergeconfig make[1]: *** No rule to make target 'kselftest-mergeconfig'. Stop. Makefile:553: recipe for target 'kselftest-mergeconfig' failed make: *** [kselftest-mergeconfig] Error 2 01234567890123456789012345678901234567890123456789012345678901234567890123456789 It works when I get rid of the config at the end of this target. So, I guess that this is because the "%config" in this Makefile. How should I overwrite this wildcard? Thanks Bamvor > > cheers > -- - arm64, kernel. opensuse blog: http://bjzhang.github.io - -- 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: Odroid U3 mutex deadlock.
Hi Anand, On 2016-01-02 06:14, Anand Moon wrote: Hi Krzysztof On 14 December 2015 at 05:15, Krzysztof Kozlowski wrote: On 12.12.2015 13:32, Anand Moon wrote: Hi Krzysztof, I am just observing this deadlock om my Odroid U3. This is not a deadlock yet, just a report from lockdep. Could be a real issue, could be false positive, maybe some locks miss nesting annotations. Typical information for bug report would be useful, like the exact version (it is mentioned in lockdep report but is it really correct?) and reproducibility. And of course git-bisect would be nice to have, see: Documentation/BUG-HUNTING Best regards, Krzysztof Thanks for your inputs. I narrowed down to this commit. -- commit ec459c0c77faca53cf161830cb264e51bb1abba6 Author: Marek Szyprowski Date: Wed Feb 4 23:44:15 2015 +0900 ARM: dts: add dependency between TV and LCD0 power domains for exynos4 TV Mixer needs both TV and LCD0 domains enabled to be fully operational. This dependency is modelled by making TV power domains a sub-domain of LCD0 power domain. Signed-off-by: Marek Szyprowski Signed-off-by: Kukjin Kim - After reverting this I am not observing below lockdep warning report. But after reverting this patch I observer another bug. The mentioned lockdep warning is a false positive. Such warning is reported for every subdomain present in a system. As you noticed that removing dependency between power domains also removes this warning, but it will introduce real problems with power on/off sequences of graphics devices. I will send a patch for genpd core fixing the deplock warning. Thanks for reporting the issue and pointing a good place to start digging in the source :) Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland -- 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 v4 net-next 2/3] net: macb: Add NPx macb config using USRIO_DISABLED cap
Le 04/01/2016 10:42, Neil Armstrong a écrit :
> Declare a new SoC variant for NPx SoCs having USRIO_DISABLED as
> capability bit.
>
> Signed-off-by: Neil Armstrong
> ---
> drivers/net/ethernet/cadence/macb.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/net/ethernet/cadence/macb.c
> b/drivers/net/ethernet/cadence/macb.c
> index fa53bc3..a9e27a7 100644
> --- a/drivers/net/ethernet/cadence/macb.c
> +++ b/drivers/net/ethernet/cadence/macb.c
> @@ -2781,6 +2781,11 @@ static const struct macb_config emac_config = {
> .init = at91ether_init,
> };
>
> +static const struct macb_config npx_config = {
> + .caps = MACB_CAPS_USRIO_DISABLED,
> + .clk_init = macb_clk_init,
> + .init = macb_init,
> +};
>
> static const struct macb_config zynqmp_config = {
> .caps = MACB_CAPS_GIGABIT_MODE_AVAILABLE | MACB_CAPS_JUMBO,
> @@ -2801,6 +2806,7 @@ static const struct of_device_id macb_dt_ids[] = {
> { .compatible = "cdns,at32ap7000-macb" },
> { .compatible = "cdns,at91sam9260-macb", .data = &at91sam9260_config },
> { .compatible = "cdns,macb" },
> + { .compatible = "cdns,npx-macb", .data = &npx_config },
I can accept that, but I think that you'd better make your device tree
compatibility string *not* generic. Name it by the first NPx SoC or
perfectly compatible SoC family that has this configuration and you'll
be able to make the NP(x+1) compatible with it.
It has proven to be much more future proof and even if in the early days
of DT on ARM we accepted some binding with generic strings like this one
below, It has proven to be a mistake.
> { .compatible = "cdns,gem", .data = &pc302gem_config },
> { .compatible = "atmel,sama5d2-gem", .data = &sama5d2_config },
>
--
Nicolas Ferre
--
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] power: genpd: fix lockdep issue for all subdomains
During genpd_poweron, genpd->lock is acquired recursively for each
parent (master) domain, which are separate obejcts. This confuses
lockdep, which considers every operation on genpd->lock as being done on
the same lock class. This leads to the following false positive warning:
=
[ INFO: possible recursive locking detected ]
4.4.0-rc4-xu3s #32 Not tainted
-
swapper/0/1 is trying to acquire lock:
(&genpd->lock){+.+...}, at: [] __genpd_poweron+0x64/0x108
but task is already holding lock:
(&genpd->lock){+.+...}, at: [] genpd_dev_pm_attach+0x168/0x1b8
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
lock(&genpd->lock);
lock(&genpd->lock);
*** DEADLOCK ***
May be due to missing lock nesting notation
3 locks held by swapper/0/1:
#0: (&dev->mutex){..}, at: [] __driver_attach+0x48/0x98
#1: (&dev->mutex){..}, at: [] __driver_attach+0x58/0x98
#2: (&genpd->lock){+.+...}, at: [] genpd_dev_pm_attach+0x168/0x1b8
stack backtrace:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.4.0-rc4-xu3s #32
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0x84/0xc4)
[] (dump_stack) from [] (__lock_acquire+0x1f88/0x215c)
[] (__lock_acquire) from [] (lock_acquire+0xa4/0xd0)
[] (lock_acquire) from [] (mutex_lock_nested+0x70/0x4d4)
[] (mutex_lock_nested) from [] (__genpd_poweron+0x64/0x108)
[] (__genpd_poweron) from []
(genpd_dev_pm_attach+0x170/0x1b8)
[] (genpd_dev_pm_attach) from []
(platform_drv_probe+0x2c/0xac)
[] (platform_drv_probe) from []
(driver_probe_device+0x208/0x2fc)
[] (driver_probe_device) from [] (__driver_attach+0x94/0x98)
[] (__driver_attach) from [] (bus_for_each_dev+0x68/0x9c)
[] (bus_for_each_dev) from [] (bus_add_driver+0x1a0/0x218)
[] (bus_add_driver) from [] (driver_register+0x78/0xf8)
[] (driver_register) from []
(exynos_drm_register_drivers+0x28/0x74)
[] (exynos_drm_register_drivers) from []
(exynos_drm_init+0x6c/0xc4)
[] (exynos_drm_init) from [] (do_one_initcall+0x90/0x1dc)
[] (do_one_initcall) from []
(kernel_init_freeable+0x158/0x1f8)
[] (kernel_init_freeable) from [] (kernel_init+0x8/0xe8)
[] (kernel_init) from [] (ret_from_fork+0x14/0x24)
This patch replaces mutex_lock with mutex_lock_nested() and uses
recursion depth to annotate each genpd->lock operation with separate
lockdep subclass.
Reported-by: Anand Moon
Signed-off-by: Marek Szyprowski
---
drivers/base/power/domain.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/drivers/base/power/domain.c b/drivers/base/power/domain.c
index b803790..e02ddf6 100644
--- a/drivers/base/power/domain.c
+++ b/drivers/base/power/domain.c
@@ -170,16 +170,15 @@ static void genpd_queue_power_off_work(struct
generic_pm_domain *genpd)
queue_work(pm_wq, &genpd->power_off_work);
}
-static int genpd_poweron(struct generic_pm_domain *genpd);
-
/**
* __genpd_poweron - Restore power to a given PM domain and its masters.
* @genpd: PM domain to power up.
+ * @depth: nesting count for lockdep.
*
* Restore power to @genpd and all of its masters so that it is possible to
* resume a device belonging to it.
*/
-static int __genpd_poweron(struct generic_pm_domain *genpd)
+static int __genpd_poweron(struct generic_pm_domain *genpd, unsigned int depth)
{
struct gpd_link *link;
int ret = 0;
@@ -194,11 +193,16 @@ static int __genpd_poweron(struct generic_pm_domain
*genpd)
* with it.
*/
list_for_each_entry(link, &genpd->slave_links, slave_node) {
- genpd_sd_counter_inc(link->master);
+ struct generic_pm_domain *master = link->master;
+
+ genpd_sd_counter_inc(master);
+
+ mutex_lock_nested(&master->lock, depth + 1);
+ ret = __genpd_poweron(master, depth + 1);
+ mutex_unlock(&master->lock);
- ret = genpd_poweron(link->master);
if (ret) {
- genpd_sd_counter_dec(link->master);
+ genpd_sd_counter_dec(master);
goto err;
}
}
@@ -230,11 +234,12 @@ static int genpd_poweron(struct generic_pm_domain *genpd)
int ret;
mutex_lock(&genpd->lock);
- ret = __genpd_poweron(genpd);
+ ret = __genpd_poweron(genpd, 0);
mutex_unlock(&genpd->lock);
return ret;
}
+
static int genpd_save_dev(struct generic_pm_domain *genpd, struct device *dev)
{
return GENPD_DEV_CALLBACK(genpd, int, save_state, dev);
@@ -482,7 +487,7 @@ static int pm_genpd_runtime_resume(struct device *dev)
}
mutex_lock(&genpd->lock);
- ret = __genpd_poweron(genpd);
+ ret = __genpd_poweron(genpd, 0);
mutex_unlock(&genpd->lock);
if (ret)
--
1.9.2
--
To unsubscribe from
Re: [PATCH 1/3] rsi: Delete unnecessary variable initialisations in rsi_send_mgmt_pkt()
> These patches are labour intensive to review because you can't just do > it in the email client. Thanks for your general interest. > Also you were not able to review it properly yourself and introduced > a bug. I admit that it can happen during my software development that I overlook implementation details somehow. > I am often remove initializers but it's normally because I am changing > something else which makes it worthwhile. It is nice to hear that you are also occasionally looking for similar update candidates. > This patch is the correct thing but it's not "worthwhile". I find this view interesting. > Please stop sending cleanup patches, Markus. Just send fixes. How often will source code clean-up fix something? May I resend a consistent patch series for the source file "drivers/net/wireless/rsi/rsi_91x_pkt.c" in the near future? Regards, Markus -- 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] udf: avoid uninitialized variable use
On Monday 04 January 2016 10:56:05 Jan Kara wrote:
> On Fri 01-01-16 15:21:54, Arnd Bergmann wrote:
> > A new warning about a real bug has come up from a recent cleanup:
> >
> > fs/udf/inode.c: In function 'udf_setup_indirect_aext':
> > fs/udf/inode.c:1927:28: warning: 'adsize' may be used uninitialized in this
> > function [-Wmaybe-uninitialized]
> >
> > If the alloc_type is neither ICBTAG_FLAG_AD_SHORT nor ICBTAG_FLAG_AD_LONG,
> > the value of adsize is undefined. This changes the code to use zero for
> > adsize
> > in that case, which may be the correct solution, though I have not looked
> > at the code in enough detail to know if it should be something else instead.
> >
> > Signed-off-by: Arnd Bergmann
> > Fixes: fcea62babc81 ("udf: Factor out code for creating indirect extent")
> > ---
> > sorry for missing another instance the first time around. The warning is
> > a bit unreliable and it seems in my first configuration I got it only
> > for one of the two instances that show it in other configuration.
> >
> > After checking the remaining functions in this file for the same possible
> > problem, I found that the other functions use either 'BUG()' or 'return
> > -EIO'
> > in the 'else' path, so I assume the two functions here should one of those
> > as well, but I don't know which.
>
> Callers of these functions make sure alloc_type is one of the two valid
> ones. However for future-proofing you're right that probably we should
> handle the invalid case as well. Setting adsize to zero is problematic -
> not sure what the code would actually do but it wouldn't definitely work.
> I'd just return -EIO. Attached is the patch I have merged.
>
>
Looks good, thanks!
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: [PATCH v2] memory-hotplug: add automatic onlining policy for the newly added memory
Andrew Morton writes:
> On Tue, 22 Dec 2015 17:32:30 +0100 Vitaly Kuznetsov
> wrote:
>
>> Currently, all newly added memory blocks remain in 'offline' state unless
>> someone onlines them, some linux distributions carry special udev rules
>> like:
>>
>> SUBSYSTEM=="memory", ACTION=="add", ATTR{state}=="offline",
>> ATTR{state}="online"
>>
>> to make this happen automatically. This is not a great solution for virtual
>> machines where memory hotplug is being used to address high memory pressure
>> situations as such onlining is slow and a userspace process doing this
>> (udev) has a chance of being killed by the OOM killer as it will probably
>> require to allocate some memory.
>>
>> Introduce default policy for the newly added memory blocks in
>> /sys/devices/system/memory/hotplug_autoonline file with two possible
>> values: "offline" which preserves the current behavior and "online" which
>> causes all newly added memory blocks to go online as soon as they're added.
>> The default is "online" when MEMORY_HOTPLUG_AUTOONLINE kernel config option
>> is selected.
>
> I think the default should be "offline" so vendors can ship kernels
> which have CONFIG_MEMORY_HOTPLUG_AUTOONLINE=y while being
> back-compatible with previous kernels.
>
(sorry for the delayed response, just picking things up after holidays)
I was under an (wrong?) impression that in the majority of use cases
users want to start using their newly added memory right away and that's
what distros will ship. As an alternative to making the feature off by
default I can suggest making CONFIG_MEMORY_HOTPLUG_AUTOONLINE a tristate
switch (no feature, default offline, default online).
>> --- a/Documentation/kernel-parameters.txt
>> +++ b/Documentation/kernel-parameters.txt
>> @@ -2537,6 +2537,8 @@ bytes respectively. Such letter suffixes can also be
>> entirely omitted.
>> shutdown the other cpus. Instead use the REBOOT_VECTOR
>> irq.
>>
>> +nomemhp_autoonline Don't automatically online newly added memory.
>> +
>
> This wasn't mentioned in the changelog. Why do we need a boot
> parameter as well as the sysfs knob?
>
I was thinking about some faulty hardware (e.g. reporting new memory
blocks which for some reason are not really usable) and an easy way to
make such hardware work.
>> +config MEMORY_HOTPLUG_AUTOONLINE
>> +bool "Automatically online hot-added memory"
>> +depends on MEMORY_HOTPLUG_SPARSE
>> +help
>> + When memory is hot-added, it is not at ready-to-use state, a special
>
> "When memory is hot-added it is not in a ready-to-use state. A special"
>
>> + userspace action is required to online the newly added blocks. With
>> + this option enabled, the kernel will try to online all newly added
>> + memory automatically.
>> +
>>
>> ...
>>
--
Vitaly
--
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/
Thoughts about introducing OPTIMIZATION_CFLAG
[ Not sure if I have addressed all the correct people and mailing-lists ]
Hi,
while still digging into a llvmlinux issue with workqueue I saw that
the wrong optimization compiler-flag was used on x86 architecture and
acpi subsystem.
CLANG requires '-Oz' whereas GCC requires '-Os'.
As acpi-daemon was throwing out the regression I looked by accident
over the *_CFLAGS.
As said... I checked only for x86 and acpi only.
For example '-Os' is hardcoded in...
arch/x86/Makefile
arch/x86/purgatory/Makefile
drivers/acpi/Makefile
drivers/acpi/acpica/Makefile
For acpi part we have currently both used '-O2' and '-Os' ('-Oz' for
llvmlinux) in approx 200 make-lines.
$ grep '\-O2' build-log_4.4.0-rc8-2-llvmlinux-amd64.txt | grep acpi | wc -l
226
$ grep '\-Oz' build-log_4.4.0-rc8-2-llvmlinux-amd64.txt | grep acpi |
grep '\-O2' | wc -l
200
So, which optimization-cflags is now used if I have both in one
make-line (and how can I check this)?
[ EXAMPLE ]
$ mycompiler --version
clang version 3.7.0 (tags/RELEASE_370/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
$ mycompiler -Wp,-MD,drivers/acpi/.video_detect.o.d -nostdinc
-isystem /opt/llvm-toolchain-3.7.0/bin/../lib/clang/3.7.0/include
-nostdinc -isystem
/opt/llvm-toolchain-3.7.0/bin/../lib/clang/3.7.0/include
-I./arch/x86/include -Iarch/x86/include/generated/uapi
-Iarch/x86/include/generated -Iinclude -I./arch/x86/include/uapi
-Iarch/x86/include/generated/uapi -I./include/uapi
-Iinclude/generated/uapi -include ./include/linux/kconfig.h
-D__KERNEL__ -Qunused-arguments -Wno-unknown-warning-option -Wall
-Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing
-fno-common -Werror-implicit-function-declaration -Wno-format-security
-std=gnu89 -no-integrated-as -mno-sse -mno-mmx -mno-sse2 -mno-3dnow
-mno-avx -m64 -mtune=generic -mno-red-zone -mcmodel=kernel
-funit-at-a-time -DCONFIG_X86_X32_ABI -DCONFIG_AS_CFI=1
-DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1
-DCONFIG_AS_FXSAVEQ=1 -DCONFIG_AS_SSSE3=1 -DCONFIG_AS_CRC32=1
-DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 -pipe -Wno-sign-compare
-fno-asynchronous-unwind-tables *** -O2 *** -Wframe-larger-than=1024
-fno-stack-protector -Wno-unused-variable
-Wno-format-invalid-specifier -Wno-gnu -Wno-asm-operand-widths
-Wno-initializer-overrides -fno-builtin -Wno-tautological-compare
-mno-global-merge -fno-omit-frame-pointer -fno-optimize-sibling-calls
-pg -Wdeclaration-after-statement -Wno-pointer-sign
-fno-strict-overflow -Werror=implicit-int -Werror=strict-prototypes
-Werror=date-time -Wno-initializer-overrides -Wno-unused-value
-Wno-format -Wno-unknown-warning-option -Wno-sign-compare
-Wno-format-zero-length -Wno-uninitialized *** -Oz *** -DMODULE
-D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(video_detect)"
-D"KBUILD_MODNAME=KBUILD_STR(video)" -c -o
drivers/acpi/.tmp_video_detect.o drivers/acpi/video_detect.c
How can I switch a optimization-cflags for certain code-parts in the
Linux-kernel (with or without the kbuild-system)?
( So the default optimization-cflags is '-O2' whereas parts wants '-Os'. )
What to do when using CONFIG_CC_OPTIMIZE_FOR_SIZE=y which sets '-Os' explicitly?
Below tools/ directory we have also an OPTIMIZATION variable used.
Something like a "global" solution is desired from my side.
I have attached a patchset on top of my llvmlinux-amd64-fixes-4.4,
hope this helps a bit to see what I mean.
It is not doing what I desire - still WIP.
Thoughts?
Thanks in advance.
Regards,
- Sedat -
From ed66e809d779d0ce5db6b71ad48792010bf6aad3 Mon Sep 17 00:00:00 2001
From: Sedat Dilek
Date: Mon, 4 Jan 2016 11:16:00 +0100
Subject: [PATCH 1/3] kbuild: Introduce OPTIMIZATION_CFLAGS
Signed-off-by: Sedat Dilek
---
Makefile | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/Makefile b/Makefile
index dcdb24b27dde..30cd406a4475 100644
--- a/Makefile
+++ b/Makefile
@@ -295,10 +295,12 @@ CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \
else if [ -x /bin/bash ]; then echo /bin/bash; \
else echo sh; fi ; fi)
+OPTIMIZATION_CFLAGS := -O2
+
HOSTCC = gcc
HOSTCXX = g++
-HOSTCFLAGS = -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer -std=gnu89
-HOSTCXXFLAGS = -O2
+HOSTCFLAGS = -Wall -Wmissing-prototypes -Wstrict-prototypes $(OPTIMIZATION_CFLAGS) -fomit-frame-pointer -std=gnu89
+HOSTCXXFLAGS = $(OPTIMIZATION_CFLAGS)
HOSTCFLAGS += -Wno-unused-value -Wno-unused-parameter -Wno-missing-field-initializers
ifneq ($(shell $(HOSTCC) -v 2>&1 | grep -c "clang version"), 1)
@@ -623,11 +625,10 @@ KBUILD_CFLAGS += $(call cc-option,-fno-delete-null-pointer-checks,)
endif
ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
-KBUILD_CFLAGS += $(call cc-option,-Oz,-Os)
+OPTIMIZATION_CFLAGS := $(call cc-option,-Oz,-Os)
KBUILD_CFLAGS += $(call cc-disable-warning,maybe-uninitialized,)
-else
-KBUILD_CFLAGS += -O2
endif
+KBUILD_CFLAGS += $(OPTIMIZATION_CFLAGS)
# Tell gcc to never replace conditional load with a non-conditional one
KBUILD
[PATCH] m68k: fix build failure
The defconfig build of m68k was failing with the error:
implicit declaration of function '__pfn_to_phys'
Other architectures have added , but if we do so here then
we will also get redeclaration of some other functions. So it is better
to copy these macros into page_mm.h.
Fixes: 0a3c3bf11240 ("x86, mm: introduce vmem_altmap to augment
vmemmap_populate()")
Cc: Dan Williams
Signed-off-by: Sudip Mukherjee
---
m68k defconfig build log of next-20160104 is at:
https://travis-ci.org/sudipm-mukherjee/parport/jobs/100068521
arch/m68k/include/asm/page_mm.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/m68k/include/asm/page_mm.h b/arch/m68k/include/asm/page_mm.h
index e7a1946..63aa14d 100644
--- a/arch/m68k/include/asm/page_mm.h
+++ b/arch/m68k/include/asm/page_mm.h
@@ -165,6 +165,9 @@ static inline __attribute_const__ int
__virt_to_node_shift(void)
((__p) - pgdat->node_mem_map) + pgdat->node_start_pfn; \
})
+#define __phys_to_pfn(paddr) ((unsigned long)((paddr) >> PAGE_SHIFT))
+#define __pfn_to_phys(pfn) PFN_PHYS(pfn)
+
#define virt_addr_valid(kaddr) ((void *)(kaddr) >= (void *)PAGE_OFFSET &&
(void *)(kaddr) < high_memory)
#define pfn_valid(pfn) virt_addr_valid(pfn_to_virt(pfn))
--
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 v2] clk:gcc-msm8916: add missing mss_q6_bimc_axi clock
This clock is required for loading the qdsp firmware.
Signed-off-by: Srinivas Kandagatla
---
Changes since v1:
fixed parent name as spotted by Georgi
drivers/clk/qcom/gcc-msm8916.c | 18 ++
include/dt-bindings/clock/qcom,gcc-msm8916.h | 1 +
2 files changed, 19 insertions(+)
diff --git a/drivers/clk/qcom/gcc-msm8916.c b/drivers/clk/qcom/gcc-msm8916.c
index e643944..89fe930 100644
--- a/drivers/clk/qcom/gcc-msm8916.c
+++ b/drivers/clk/qcom/gcc-msm8916.c
@@ -2590,6 +2590,23 @@ static struct clk_branch gcc_mss_cfg_ahb_clk = {
},
};
+static struct clk_branch gcc_mss_q6_bimc_axi_clk = {
+ .halt_reg = 0x49004,
+ .clkr = {
+ .enable_reg = 0x49004,
+ .enable_mask = BIT(0),
+ .hw.init = &(struct clk_init_data){
+ .name = "gcc_mss_q6_bimc_axi_clk",
+ .parent_names = (const char *[]){
+ "bimc_ddr_clk_src",
+ },
+ .num_parents = 1,
+ .flags = CLK_SET_RATE_PARENT,
+ .ops = &clk_branch2_ops,
+ },
+ },
+};
+
static struct clk_branch gcc_oxili_ahb_clk = {
.halt_reg = 0x59028,
.clkr = {
@@ -3228,6 +3245,7 @@ static struct clk_regmap *gcc_msm8916_clocks[] = {
[GCC_ULTAUDIO_LPAIF_SEC_I2S_CLK] = &gcc_ultaudio_lpaif_sec_i2s_clk.clkr,
[GCC_ULTAUDIO_LPAIF_AUX_I2S_CLK] = &gcc_ultaudio_lpaif_aux_i2s_clk.clkr,
[GCC_CODEC_DIGCODEC_CLK] = &gcc_codec_digcodec_clk.clkr,
+ [GCC_MSS_Q6_BIMC_AXI_CLK] = &gcc_mss_q6_bimc_axi_clk.clkr,
};
static struct gdsc *gcc_msm8916_gdscs[] = {
diff --git a/include/dt-bindings/clock/qcom,gcc-msm8916.h
b/include/dt-bindings/clock/qcom,gcc-msm8916.h
index 257e2fb..28a27a4 100644
--- a/include/dt-bindings/clock/qcom,gcc-msm8916.h
+++ b/include/dt-bindings/clock/qcom,gcc-msm8916.h
@@ -174,6 +174,7 @@
#define GCC_ULTAUDIO_LPAIF_SEC_I2S_CLK 157
#define GCC_ULTAUDIO_LPAIF_AUX_I2S_CLK 158
#define GCC_CODEC_DIGCODEC_CLK 159
+#define GCC_MSS_Q6_BIMC_AXI_CLK160
/* Indexes for GDSCs */
#define BIMC_GDSC 0
--
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 05/13] arm64: kvm: deal with kernel symbols outside of linear mapping
On 04/01/16 10:31, Ard Biesheuvel wrote:
> On 4 January 2016 at 11:08, Marc Zyngier wrote:
>> Hi Ard,
>>
>> On 30/12/15 15:26, Ard Biesheuvel wrote:
>>> KVM on arm64 uses a fixed offset between the linear mapping at EL1 and
>>> the HYP mapping at EL2. Before we can move the kernel virtual mapping
>>> out of the linear mapping, we have to make sure that references to kernel
>>> symbols that are accessed via the HYP mapping are translated to their
>>> linear equivalent.
>>>
>>> To prevent inadvertent direct references from sneaking in later, change
>>> the type of all extern declarations to HYP kernel symbols to the opaque
>>> 'struct kvm_ksym', which does not decay to a pointer type like char arrays
>>> and function references. This is not bullet proof, but at least forces the
>>> user to take the address explicitly rather than referencing it directly.
>>>
>>> Signed-off-by: Ard Biesheuvel
>>
>> This looks good to me, a few comments below.
>>
>>> ---
>>> arch/arm/include/asm/kvm_asm.h | 2 ++
>>> arch/arm/include/asm/kvm_mmu.h | 2 ++
>>> arch/arm/kvm/arm.c | 9 +
>>> arch/arm/kvm/mmu.c | 12 +--
>>> arch/arm64/include/asm/kvm_asm.h | 21 +++-
>>> arch/arm64/include/asm/kvm_mmu.h | 2 ++
>>> arch/arm64/include/asm/virt.h| 4
>>> arch/arm64/kernel/vmlinux.lds.S | 4 ++--
>>> arch/arm64/kvm/debug.c | 4 +++-
>>> virt/kvm/arm/vgic-v3.c | 2 +-
>>> 10 files changed, 34 insertions(+), 28 deletions(-)
>>>
>>> diff --git a/arch/arm/include/asm/kvm_asm.h b/arch/arm/include/asm/kvm_asm.h
>>> index 194c91b610ff..484ffdf7c70b 100644
>>> --- a/arch/arm/include/asm/kvm_asm.h
>>> +++ b/arch/arm/include/asm/kvm_asm.h
>>> @@ -99,6 +99,8 @@ extern void __kvm_tlb_flush_vmid_ipa(struct kvm *kvm,
>>> phys_addr_t ipa);
>>> extern void __kvm_tlb_flush_vmid(struct kvm *kvm);
>>>
>>> extern int __kvm_vcpu_run(struct kvm_vcpu *vcpu);
>>> +
>>> +extern char __hyp_idmap_text_start[], __hyp_idmap_text_end[];
>>> #endif
>>>
>>> #endif /* __ARM_KVM_ASM_H__ */
>>> diff --git a/arch/arm/include/asm/kvm_mmu.h b/arch/arm/include/asm/kvm_mmu.h
>>> index 405aa1883307..412b363f79e9 100644
>>> --- a/arch/arm/include/asm/kvm_mmu.h
>>> +++ b/arch/arm/include/asm/kvm_mmu.h
>>> @@ -30,6 +30,8 @@
>>> #define HYP_PAGE_OFFSET PAGE_OFFSET
>>> #define KERN_TO_HYP(kva) (kva)
>>>
>>> +#define kvm_ksym_ref(kva)(kva)
>>> +
>>> /*
>>> * Our virtual mapping for the boot-time MMU-enable code. Must be
>>> * shared across all the page-tables. Conveniently, we use the vectors
>>> diff --git a/arch/arm/kvm/arm.c b/arch/arm/kvm/arm.c
>>> index e06fd299de08..014b542ea658 100644
>>> --- a/arch/arm/kvm/arm.c
>>> +++ b/arch/arm/kvm/arm.c
>>> @@ -427,7 +42You can use it, but you don't have to, since yo7,7 @@ static
>>> void update_vttbr(struct kvm *kvm)
>>>* shareable domain to make sure all data structures are
>>>* clean.
>>>*/
>>> - kvm_call_hyp(__kvm_flush_vm_context);
>>> + kvm_call_hyp(kvm_ksym_ref(__kvm_flush_vm_context));
>>> }
>>>
>>> kvm->arch.vmid_gen = atomic64_read(&kvm_vmid_gen);
>>> @@ -600,7 +600,7 @@ int kvm_arch_vcpu_ioctl_run(struct kvm_vcpu *vcpu,
>>> struct kvm_run *run)
>>> __kvm_guest_enter();
>>> vcpu->mode = IN_GUEST_MODE;
>>>
>>> - ret = kvm_call_hyp(__kvm_vcpu_run, vcpu);
>>> + ret = kvm_call_hyp(kvm_ksym_ref(__kvm_vcpu_run), vcpu);
>>>
>>> vcpu->mode = OUTSIDE_GUEST_MODE;
>>> /*
>>> @@ -969,7 +969,7 @@ static void cpu_init_hyp_mode(void *dummy)
>>> pgd_ptr = kvm_mmu_get_httbr();
>>> stack_page = __this_cpu_read(kvm_arm_hyp_stack_page);
>>> hyp_stack_ptr = stack_page + PAGE_SIZE;
>>> - vector_ptr = (unsigned long)__kvm_hyp_vector;
>>> + vector_ptr = (unsigned long)kvm_ksym_ref(__kvm_hyp_vector);
>>>
>>> __cpu_init_hyp_mode(boot_pgd_ptr, pgd_ptr, hyp_stack_ptr, vector_ptr);
>>>
>>> @@ -1061,7 +1061,8 @@ static int init_hyp_mode(void)
>>> /*
>>>* Map the Hyp-code called directly from the host
>>>*/
>>> - err = create_hyp_mappings(__kvm_hyp_code_start, __kvm_hyp_code_end);
>>> + err = create_hyp_mappings(kvm_ksym_ref(__kvm_hyp_code_start),
>>> + kvm_ksym_ref(__kvm_hyp_code_end));
>>> if (err) {
>>> kvm_err("Cannot map world-switch code\n");
>>> goto out_free_mappings;
>>> diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
>>> index 7dace909d5cf..7c448b943e3a 100644
>>> --- a/arch/arm/kvm/mmu.c
>>> +++ b/arch/arm/kvm/mmu.c
>>> @@ -31,8 +31,6 @@
>>>
>>> #include "trace.h"
>>>
>>> -extern char __hyp_idmap_text_start[], __hyp_idmap_text_end[];
>>> -
>>> static pgd_t *boot_hyp_pgd;
>>> static pgd_t *hyp_pgd;
>>> static pgd_t *merged_hyp_pgd;
>>> @@ -63,7 +61,7 @@ static bool memslot_is_logging(struct kvm_memory_slot
>>> *m
Re: [PATCH v2 14/16] x86,nvdimm,kexec: Use walk_iomem_res_desc() for iomem search
On 01/04/16 at 05:25pm, Dave Young wrote:
> Hi, Toshi,
>
> On 12/25/15 at 03:09pm, Toshi Kani wrote:
> > Change to call walk_iomem_res_desc() for searching resource entries
> > with the following names:
> > "ACPI Tables"
> > "ACPI Non-volatile Storage"
> > "Persistent Memory (legacy)"
> > "Crash kernel"
> >
> > Note, the caller of walk_iomem_res() with "GART" is left unchanged
> > because this entry may be initialized by out-of-tree drivers, which
> > do not have 'desc' set to IORES_DESC_GART.
>
> Found below commit which initialize the GART entry:
> commit 56dd669a138c40ea6cdae487f233430d12372767
> Author: Aaron Durbin
> Date: Tue Sep 26 10:52:40 2006 +0200
>
> [PATCH] Insert GART region into resource map
>
> Patch inserts the GART region into the iomem resource map. The GART will
> then
> be visible within /proc/iomem. It will also allow for other users
> utilizing the GART to subreserve the region (agp or IOMMU).
>
> Signed-off-by: Aaron Durbin
>
> But later it was reverted:
> commit 707d4eefbdb31f8e588277157056b0ce637d6c68
> Author: Bjorn Helgaas
> Date: Tue Mar 18 14:26:12 2014 -0600
>
> Revert "[PATCH] Insert GART region into resource map"
>
> This reverts commit 56dd669a138c, which makes the GART visible in
> /proc/iomem. This fixes a regression: e501b3d87f00 ("agp: Support 64-bit
> APBASE") exposed an existing problem with a conflict between the GART
> region and a PCI BAR region.
>
> The GART addresses are bus addresses, not CPU addresses, and therefore
> should not be inserted in iomem_resource.
>
> On many machines, the GART region is addressable by the CPU as well as by
> an AGP master, but CPU addressability is not required by the spec. On
> some
> of these machines, the GART is mapped by a PCI BAR, and in that case, the
> PCI core automatically inserts it into iomem_resource, just as it does for
> all BARs.
>
> Inserting it here means we'll have a conflict if the PCI core later tries
> to claim the GART region, so let's drop the insertion here.
>
> The conflict indirectly causes X failures, as reported by Jouni in the
> bugzilla below. We detected the conflict even before e501b3d87f00, but
> after it the AGP code (fix_northbridge()) uses the PCI resource (which is
> zeroed because of the conflict) instead of reading the BAR again.
>
> Conflicts:
> arch/x86_64/kernel/aperture.c
>
> Fixes: e501b3d87f00 agp: Support 64-bit APBASE
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=72201
> Reported-and-tested-by: Jouni Mettälä
> Signed-off-by: Bjorn Helgaas
>
>
> For amd64 agp, currently the region name is "aperture" instead:
> drivers/char/agp/amd64-agp.c: agp_aperture_valid()
>
> This may not be the only case, but I doubt that anyone is testing this since
> long time ago kexec-tools excluding the 'GART' region. Kexec-tools and
> kexec_file
> may need update to use "aperture" if someone can test it.
>
> I think adding an enum value for compatibility is reasonable, we do not care
> about third party drivers in mainline.
Hmm, rethink about it, the new kernel will not export "GART" regions thus the
in-kernel loader should never see such regions as long as there's no other
drivers exporting it. Thus dropping the code chunk in crash.c about 'GART'
should be fine.
Thanks
Dave
--
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/
