Re: [PATCH v3 1/2] GPIO: add single-register GPIO via CREG driver
Hi Eugeniy,
sorry for the delay, the driver is different from what I'm
used to so I needed focuses attention and it took some time.
On Tue, Sep 11, 2018 at 5:09 PM Eugeniy Paltsev
wrote:
> Add single-register MMIO GPIO driver for complex cases where
> only several fields in register belong to GPIO lines and each GPIO
> line owns a field with different length and on/off value.
>
> Such CREG GPIOs are used in Synopsys AXS10x and HSDK boards.
>
> Signed-off-by: Eugeniy Paltsev
> ---
> Changes v2->v3:
> * Move parameters into a lookup table instead of device tree.
> * Use the ngpios attribute for instead of snps,ngpios.
This is looking good! Just a few small things I want you to fix
(we can certainly queue this for the next kernel):
> +#include
> +#include
> +#include
> +#include
Replace this with:
#include
Drivers should only need to include that file. (Also move away from
mm_gpio_chip as per below.)
> +#include "gpiolib.h"
Why?
> +struct creg_gpio {
> + struct of_mm_gpio_chip mmchip;
I would prefer to move away from using this. Just create a regular driver
please. Just struct gpio_chip and add a member
void __iomem *base; instead of referring to mmchip.regs.
In fact I want to rewrite all mm_gpio_chips but I just haven't had time.
> +static void creg_gpio_set(struct gpio_chip *gc, unsigned int gpio, int val)
Please rename the variable "gpio" to "offset".
This is clearer because "gpio" becomes quite ambigous.
> +static int creg_gpio_get_direction(struct gpio_chip *gc, unsigned int offset)
> +{
> + return 0; /* output */
> +}
I think with the recent code changes in gpiolib you do not need to define
this function at all.
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/commit/?h=devel&id=ae9847f48a4b4bff0335da20be63ac84d94eb54c
> +static int creg_gpio_xlate(struct gpio_chip *gc,
> + const struct of_phandle_args *gpiospec, u32 *flags)
> +{
> + if (gpiospec->args_count != 1) {
> + dev_err(&gc->gpiodev->dev, "invalid args_count: %d\n",
> + gpiospec->args_count);
> + return -EINVAL;
> + }
> +
> + if (gpiospec->args[0] >= gc->ngpio) {
> + dev_err(&gc->gpiodev->dev, "gpio number is too big: %d\n",
> + gpiospec->args[0]);
> + return -EINVAL;
> + }
> +
> + return gpiospec->args[0];
> +}
Another reason to not use mm_gpio_chip: just rely on standard twocell
translation and you can delete this.
> + /* Check that we suit in 32 bit register */
s/suit/fit
Yours,
Linus Walleij
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3 2/2] dt-bindings: Document the Synopsys GPIO via CREG bindings
On Tue, Sep 11, 2018 at 5:09 PM Eugeniy Paltsev wrote: > This patch adds documentation of device tree bindings for the Synopsys > GPIO via CREG driver. > > Signed-off-by: Eugeniy Paltsev Reviewed-by: Linus Walleij This is fine, just waiting for the final version of the driver. Yours, Linus Walleij ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 02/30] mm: remove CONFIG_NO_BOOTMEM
On Fri 14-09-18 15:10:17, Mike Rapoport wrote: > All achitectures select NO_BOOTMEM which essentially becomes 'Y' for any > kernel configuration and therefore it can be removed. git grep suggests that DEFERRED_STRUCT_PAGE_INIT still depends on NO_BOOTMEM but I have a vague feeling that I've seen a patch to address that. It would be great to have it folded to this one. > Signed-off-by: Mike Rapoport Acked-by: Michal Hocko -- Michal Hocko SUSE Labs ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 03/30] mm: remove CONFIG_HAVE_MEMBLOCK
On Fri 14-09-18 15:10:18, Mike Rapoport wrote: > All architecures use memblock for early memory management. There is no need > for the CONFIG_HAVE_MEMBLOCK configuration option. git grep says arch/csky/Kconfig: select HAVE_MEMBLOCK > Signed-off-by: Mike Rapoport Other than that Acked-by: Michal Hocko -- Michal Hocko SUSE Labs ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 05/30] mm: nobootmem: remove dead code
On Fri 14-09-18 15:10:20, Mike Rapoport wrote: > Several bootmem functions and macros are not used. Remove them. > > Signed-off-by: Mike Rapoport Acked-by: Michal Hocko -- Michal Hocko SUSE Labs ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 14/30] memblock: add align parameter to memblock_alloc_node()
On Fri 14-09-18 15:10:29, Mike Rapoport wrote:
> With the align parameter memblock_alloc_node() can be used as drop in
> replacement for alloc_bootmem_pages_node() and __alloc_bootmem_node(),
> which is done in the following patches.
/me confused. Why do we need this patch at all? Maybe it should be
folded into the later patch you are refereing here?
> Signed-off-by: Mike Rapoport
> ---
> include/linux/bootmem.h | 4 ++--
> mm/sparse.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/bootmem.h b/include/linux/bootmem.h
> index 7d91f0f..3896af2 100644
> --- a/include/linux/bootmem.h
> +++ b/include/linux/bootmem.h
> @@ -157,9 +157,9 @@ static inline void * __init memblock_alloc_from_nopanic(
> }
>
> static inline void * __init memblock_alloc_node(
> - phys_addr_t size, int nid)
> + phys_addr_t size, phys_addr_t align, int nid)
> {
> - return memblock_alloc_try_nid(size, 0, BOOTMEM_LOW_LIMIT,
> + return memblock_alloc_try_nid(size, align, BOOTMEM_LOW_LIMIT,
> BOOTMEM_ALLOC_ACCESSIBLE, nid);
> }
>
> diff --git a/mm/sparse.c b/mm/sparse.c
> index 04e97af..509828f 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
> @@ -68,7 +68,7 @@ static noinline struct mem_section __ref
> *sparse_index_alloc(int nid)
> if (slab_is_available())
> section = kzalloc_node(array_size, GFP_KERNEL, nid);
> else
> - section = memblock_alloc_node(array_size, nid);
> + section = memblock_alloc_node(array_size, 0, nid);
>
> return section;
> }
> --
> 2.7.4
>
--
Michal Hocko
SUSE Labs
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 07/30] memblock: remove _virt from APIs returning virtual address
On Fri 14-09-18 15:10:22, Mike Rapoport wrote: > The conversion is done using > > sed -i 's@memblock_virt_alloc@memblock_alloc@g' \ > $(git grep -l memblock_virt_alloc) > > Signed-off-by: Mike Rapoport As I've said earlier, I am not entirely thrilled by this change. It is unnecessary churn. So if nothing else just add a note _why_ you think this is better. -- Michal Hocko SUSE Labs ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 14/30] memblock: add align parameter to memblock_alloc_node()
On Wed 26-09-18 11:31:27, Michal Hocko wrote: > On Fri 14-09-18 15:10:29, Mike Rapoport wrote: > > With the align parameter memblock_alloc_node() can be used as drop in > > replacement for alloc_bootmem_pages_node() and __alloc_bootmem_node(), > > which is done in the following patches. > > /me confused. Why do we need this patch at all? Maybe it should be > folded into the later patch you are refereing here? OK, I can see 1536927045-23536-17-git-send-email-r...@linux.vnet.ibm.com now. If you are going to repost for whatever reason please merge those two. Also I would get rid of the implicit "0 implies SMP_CACHE_BYTES" behavior. It is subtle and you have to dig deep to find that out. Why not make it explicit? -- Michal Hocko SUSE Labs ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 16/30] memblock: replace __alloc_bootmem_node with appropriate memblock_ API
On Fri 14-09-18 15:10:31, Mike Rapoport wrote: > Use memblock_alloc_try_nid whenever goal (i.e. minimal address is > specified) and memblock_alloc_node otherwise. > > Signed-off-by: Mike Rapoport Acked-by: Michal Hocko -- Michal Hocko SUSE Labs ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 21/30] memblock: replace alloc_bootmem with memblock_alloc
On Fri 14-09-18 15:10:36, Mike Rapoport wrote:
> The alloc_bootmem(size) is a shortcut for allocation of SMP_CACHE_BYTES
> aligned memory. When the align parameter of memblock_alloc() is 0, the
> alignment is implicitly set to SMP_CACHE_BYTES and thus alloc_bootmem(size)
> and memblock_alloc(size, 0) are equivalent.
>
> The conversion is done using the following semantic patch:
>
> @@
> expression size;
> @@
> - alloc_bootmem(size)
> + memblock_alloc(size, 0)
As mentioned in other email, please make it explicit SMP_CACHE_BYTES.
> Signed-off-by: Mike Rapoport
> ---
> arch/alpha/kernel/core_marvel.c | 4 ++--
> arch/alpha/kernel/pci-noop.c| 4 ++--
> arch/alpha/kernel/pci.c | 4 ++--
> arch/alpha/kernel/pci_iommu.c | 4 ++--
> arch/ia64/kernel/mca.c | 4 ++--
> arch/ia64/mm/tlb.c | 4 ++--
> arch/m68k/sun3/sun3dvma.c | 3 ++-
> arch/microblaze/mm/init.c | 2 +-
> arch/mips/kernel/setup.c| 2 +-
> arch/um/drivers/net_kern.c | 2 +-
> arch/um/drivers/vector_kern.c | 2 +-
> arch/um/kernel/initrd.c | 2 +-
> arch/x86/kernel/acpi/boot.c | 3 ++-
> arch/x86/kernel/apic/io_apic.c | 2 +-
> arch/x86/kernel/e820.c | 2 +-
> arch/x86/platform/olpc/olpc_dt.c| 2 +-
> arch/xtensa/platforms/iss/network.c | 2 +-
> drivers/macintosh/smu.c | 2 +-
> init/main.c | 4 ++--
> 19 files changed, 28 insertions(+), 26 deletions(-)
>
> diff --git a/arch/alpha/kernel/core_marvel.c b/arch/alpha/kernel/core_marvel.c
> index bdebb8c2..1f00c94 100644
> --- a/arch/alpha/kernel/core_marvel.c
> +++ b/arch/alpha/kernel/core_marvel.c
> @@ -82,7 +82,7 @@ mk_resource_name(int pe, int port, char *str)
> char *name;
>
> sprintf(tmp, "PCI %s PE %d PORT %d", str, pe, port);
> - name = alloc_bootmem(strlen(tmp) + 1);
> + name = memblock_alloc(strlen(tmp) + 1, 0);
> strcpy(name, tmp);
>
> return name;
> @@ -117,7 +117,7 @@ alloc_io7(unsigned int pe)
> return NULL;
> }
>
> - io7 = alloc_bootmem(sizeof(*io7));
> + io7 = memblock_alloc(sizeof(*io7), 0);
> io7->pe = pe;
> raw_spin_lock_init(&io7->irq_lock);
>
> diff --git a/arch/alpha/kernel/pci-noop.c b/arch/alpha/kernel/pci-noop.c
> index c7c5879..59cbfc2 100644
> --- a/arch/alpha/kernel/pci-noop.c
> +++ b/arch/alpha/kernel/pci-noop.c
> @@ -33,7 +33,7 @@ alloc_pci_controller(void)
> {
> struct pci_controller *hose;
>
> - hose = alloc_bootmem(sizeof(*hose));
> + hose = memblock_alloc(sizeof(*hose), 0);
>
> *hose_tail = hose;
> hose_tail = &hose->next;
> @@ -44,7 +44,7 @@ alloc_pci_controller(void)
> struct resource * __init
> alloc_resource(void)
> {
> - return alloc_bootmem(sizeof(struct resource));
> + return memblock_alloc(sizeof(struct resource), 0);
> }
>
> SYSCALL_DEFINE3(pciconfig_iobase, long, which, unsigned long, bus,
> diff --git a/arch/alpha/kernel/pci.c b/arch/alpha/kernel/pci.c
> index c668c3b..4cc3eb9 100644
> --- a/arch/alpha/kernel/pci.c
> +++ b/arch/alpha/kernel/pci.c
> @@ -392,7 +392,7 @@ alloc_pci_controller(void)
> {
> struct pci_controller *hose;
>
> - hose = alloc_bootmem(sizeof(*hose));
> + hose = memblock_alloc(sizeof(*hose), 0);
>
> *hose_tail = hose;
> hose_tail = &hose->next;
> @@ -403,7 +403,7 @@ alloc_pci_controller(void)
> struct resource * __init
> alloc_resource(void)
> {
> - return alloc_bootmem(sizeof(struct resource));
> + return memblock_alloc(sizeof(struct resource), 0);
> }
>
>
> diff --git a/arch/alpha/kernel/pci_iommu.c b/arch/alpha/kernel/pci_iommu.c
> index 0c05493..5d178c7 100644
> --- a/arch/alpha/kernel/pci_iommu.c
> +++ b/arch/alpha/kernel/pci_iommu.c
> @@ -79,7 +79,7 @@ iommu_arena_new_node(int nid, struct pci_controller *hose,
> dma_addr_t base,
> printk("%s: couldn't allocate arena from node %d\n"
> "falling back to system-wide allocation\n",
> __func__, nid);
> - arena = alloc_bootmem(sizeof(*arena));
> + arena = memblock_alloc(sizeof(*arena), 0);
> }
>
> arena->ptes = memblock_alloc_node(sizeof(*arena), align, nid);
> @@ -92,7 +92,7 @@ iommu_arena_new_node(int nid, struct pci_controller *hose,
> dma_addr_t base,
>
> #else /* CONFIG_DISCONTIGMEM */
>
> - arena = alloc_bootmem(sizeof(*arena));
> + arena = memblock_alloc(sizeof(*arena), 0);
> arena->ptes = memblock_alloc_from(mem_size, align, 0);
>
> #endif /* CONFIG_DISCONTIGMEM */
> diff --git a/arch/ia64/kernel/mca.c b/arch/ia64/kernel/mca.c
> index 5586926..7120976 100644
> --- a/arch/ia64/kernel/mca.c
> +++ b/arch/ia64/kernel/mca.c
> @@ -361,9 +361,9 @@ static ia64_state_log_t
> ia64_state_log[IA64_MAX_LOG_TYPES];
>
> #define IA64_LOG_ALLOCATE(it, size) \
> {ia64_state_log[it].isl_log[IA64_LOG_CURR_INDEX(
Re: [PATCH 29/30] mm: remove include/linux/bootmem.h
On Fri 14-09-18 15:10:44, Mike Rapoport wrote: > Move remaining definitions and declarations from include/linux/bootmem.h > into include/linux/memblock.h and remove the redundant header. > > The includes were replaced with the semantic patch below and then > semi-automated removal of duplicated '#include > > @@ > @@ > - #include > + #include > > Signed-off-by: Mike Rapoport Acked-by: Michal Hocko -- Michal Hocko SUSE Labs ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 00/30] mm: remove bootmem allocator
On Fri 14-09-18 15:10:15, Mike Rapoport wrote: [...] > 326 files changed, 866 insertions(+), 2539 deletions(-) > delete mode 100644 include/linux/bootmem.h > delete mode 100644 mm/bootmem.c > delete mode 100644 mm/nobootmem.c I _really_ love this part the most! Not only we got rid of the translation which always has been a headache but also this nicely shows how having multiple allocators hurt. I believe further cleanups on top will make the boot allocator even a place where you look and your eyes do not want to jump out. I have only went through patches without my acks from the previous iteration and there are only minor comments. This looks good overall. Nice work Mike! -- Michal Hocko SUSE Labs ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 02/30] mm: remove CONFIG_NO_BOOTMEM
On Wed, Sep 26, 2018 at 11:22:39AM +0200, Michal Hocko wrote: > On Fri 14-09-18 15:10:17, Mike Rapoport wrote: > > All achitectures select NO_BOOTMEM which essentially becomes 'Y' for any > > kernel configuration and therefore it can be removed. > > git grep suggests that DEFERRED_STRUCT_PAGE_INIT still depends on > NO_BOOTMEM but I have a vague feeling that I've seen a patch to address > that. It would be great to have it folded to this one. Yes, Alexander has already fixed that at [1] [1] https://lkml.org/lkml/2018/9/25/1073 > > Signed-off-by: Mike Rapoport > > Acked-by: Michal Hocko > -- > Michal Hocko > SUSE Labs > -- Sincerely yours, Mike. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 03/30] mm: remove CONFIG_HAVE_MEMBLOCK
On Wed, Sep 26, 2018 at 11:24:04AM +0200, Michal Hocko wrote: > On Fri 14-09-18 15:10:18, Mike Rapoport wrote: > > All architecures use memblock for early memory management. There is no need > > for the CONFIG_HAVE_MEMBLOCK configuration option. > > git grep says > arch/csky/Kconfig: select HAVE_MEMBLOCK Not only that, there are other bootmem leftovers in csky. I've sent the patch with the necessary fixups [1] [1] https://lkml.kernel.org/lkml/20180926112744.GC4628@rapoport-lnx/ > > Signed-off-by: Mike Rapoport > > Other than that > Acked-by: Michal Hocko > -- > Michal Hocko > SUSE Labs > -- Sincerely yours, Mike. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 14/30] memblock: add align parameter to memblock_alloc_node()
On Wed, Sep 26, 2018 at 11:36:48AM +0200, Michal Hocko wrote: > On Wed 26-09-18 11:31:27, Michal Hocko wrote: > > On Fri 14-09-18 15:10:29, Mike Rapoport wrote: > > > With the align parameter memblock_alloc_node() can be used as drop in > > > replacement for alloc_bootmem_pages_node() and __alloc_bootmem_node(), > > > which is done in the following patches. > > > > /me confused. Why do we need this patch at all? Maybe it should be > > folded into the later patch you are refereing here? > > OK, I can see 1536927045-23536-17-git-send-email-r...@linux.vnet.ibm.com > now. If you are going to repost for whatever reason please merge those > two. Also I would get rid of the implicit "0 implies SMP_CACHE_BYTES" > behavior. It is subtle and you have to dig deep to find that out. Why > not make it explicit? Agree. I'd just prefer to make it a separate patch rather then resend the whole series. > -- > Michal Hocko > SUSE Labs > -- Sincerely yours, Mike. ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 14/30] memblock: add align parameter to memblock_alloc_node()
On Wed 26-09-18 16:43:35, Mike Rapoport wrote: > On Wed, Sep 26, 2018 at 11:36:48AM +0200, Michal Hocko wrote: > > On Wed 26-09-18 11:31:27, Michal Hocko wrote: > > > On Fri 14-09-18 15:10:29, Mike Rapoport wrote: > > > > With the align parameter memblock_alloc_node() can be used as drop in > > > > replacement for alloc_bootmem_pages_node() and __alloc_bootmem_node(), > > > > which is done in the following patches. > > > > > > /me confused. Why do we need this patch at all? Maybe it should be > > > folded into the later patch you are refereing here? > > > > OK, I can see 1536927045-23536-17-git-send-email-r...@linux.vnet.ibm.com > > now. If you are going to repost for whatever reason please merge those > > two. Also I would get rid of the implicit "0 implies SMP_CACHE_BYTES" > > behavior. It is subtle and you have to dig deep to find that out. Why > > not make it explicit? > > Agree. I'd just prefer to make it a separate patch rather then resend the > whole series. Sure, no objection from me. -- Michal Hocko SUSE Labs ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] DRM: VBLANK: provide valid timestamp for EVENT_FLIP
If driver/HW doesn't support vblank functionality (for example
UDL driver, ARCPGU driver, ...) we always have vblank->time == 0.
In result we always provide zero timestamp for
DRM_EVENT_FLIP_COMPLETE. This breaks userspace apps (for example
weston) which relies on timestamp value.
Setup time to provide valid timestamp for DRM_EVENT_FLIP_COMPLETE
event.
Cc: sta...@vger.kernel.org
Signed-off-by: Eugeniy Paltsev
---
drivers/gpu/drm/drm_vblank.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 28cdcf76b6f9..0d19aca48782 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -911,6 +911,15 @@ void drm_crtc_send_vblank_event(struct drm_crtc *crtc,
if (dev->num_crtcs > 0) {
seq = drm_vblank_count_and_time(dev, pipe, &now);
+
+ /*
+* If driver/HW doesn't support vblank functionality we
+* always have vblank->time == 0. Setup time to provide valid
+* timestamp for DRM_EVENT_FLIP_COMPLETE event.
+*/
+ if (!now && e->event.base.type == DRM_EVENT_FLIP_COMPLETE)
+ now = ktime_get();
+
} else {
seq = 0;
--
2.14.4
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] DRM: VBLANK: provide valid timestamp for EVENT_FLIP
On Wed, Sep 26, 2018 at 05:25:35PM +0300, Eugeniy Paltsev wrote:
> If driver/HW doesn't support vblank functionality (for example
> UDL driver, ARCPGU driver, ...) we always have vblank->time == 0.
> In result we always provide zero timestamp for
> DRM_EVENT_FLIP_COMPLETE. This breaks userspace apps (for example
> weston) which relies on timestamp value.
>
> Setup time to provide valid timestamp for DRM_EVENT_FLIP_COMPLETE
> event.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Eugeniy Paltsev
> ---
> drivers/gpu/drm/drm_vblank.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index 28cdcf76b6f9..0d19aca48782 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -911,6 +911,15 @@ void drm_crtc_send_vblank_event(struct drm_crtc *crtc,
>
> if (dev->num_crtcs > 0) {
If those drivers don't support vblank stuff why are they calling
drm_vblank_init() w/ num_crtcs > 0? If they didn't they'd take the
else branch which already does what you want.
> seq = drm_vblank_count_and_time(dev, pipe, &now);
> +
> + /*
> + * If driver/HW doesn't support vblank functionality we
> + * always have vblank->time == 0. Setup time to provide valid
> + * timestamp for DRM_EVENT_FLIP_COMPLETE event.
> + */
> + if (!now && e->event.base.type == DRM_EVENT_FLIP_COMPLETE)
> + now = ktime_get();
> +
> } else {
> seq = 0;
>
> --
> 2.14.4
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Ville Syrjälä
Intel
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 03/30] mm: remove CONFIG_HAVE_MEMBLOCK
On Fri, Sep 14, 2018 at 5:11 AM Mike Rapoport wrote:
>
> All architecures use memblock for early memory management. There is no need
> for the CONFIG_HAVE_MEMBLOCK configuration option.
>
> Signed-off-by: Mike Rapoport
> diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> index 5169205..4ae91fc 100644
> --- a/include/linux/memblock.h
> +++ b/include/linux/memblock.h
> @@ -2,7 +2,6 @@
> #define _LINUX_MEMBLOCK_H
> #ifdef __KERNEL__
>
> -#ifdef CONFIG_HAVE_MEMBLOCK
> /*
> * Logical memory blocks.
> *
> @@ -460,7 +459,6 @@ static inline phys_addr_t memblock_alloc(phys_addr_t
> size, phys_addr_t align)
> {
> return 0;
> }
> -#endif /* CONFIG_HAVE_MEMBLOCK */
>
> #endif /* __KERNEL__ */
There was an #else above this section and I believe it and the code
after it needs to be stripped as well.
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 03/30] mm: remove CONFIG_HAVE_MEMBLOCK
On Wed, Sep 26, 2018 at 09:58:41AM -0700, Alexander Duyck wrote:
> On Fri, Sep 14, 2018 at 5:11 AM Mike Rapoport wrote:
> >
> > All architecures use memblock for early memory management. There is no need
> > for the CONFIG_HAVE_MEMBLOCK configuration option.
> >
> > Signed-off-by: Mike Rapoport
>
>
>
> > diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> > index 5169205..4ae91fc 100644
> > --- a/include/linux/memblock.h
> > +++ b/include/linux/memblock.h
> > @@ -2,7 +2,6 @@
> > #define _LINUX_MEMBLOCK_H
> > #ifdef __KERNEL__
> >
> > -#ifdef CONFIG_HAVE_MEMBLOCK
> > /*
> > * Logical memory blocks.
> > *
> > @@ -460,7 +459,6 @@ static inline phys_addr_t memblock_alloc(phys_addr_t
> > size, phys_addr_t align)
> > {
> > return 0;
> > }
> > -#endif /* CONFIG_HAVE_MEMBLOCK */
> >
> > #endif /* __KERNEL__ */
>
> There was an #else above this section and I believe it and the code
> after it needs to be stripped as well.
Right, I've already sent the fix [1] and it's in mmots.
[1] https://lkml.org/lkml/2018/9/19/416
--
Sincerely yours,
Mike.
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v3 2/2] dt-bindings: Document the Synopsys GPIO via CREG bindings
On Tue, 11 Sep 2018 18:09:25 +0300, Eugeniy Paltsev wrote: > This patch adds documentation of device tree bindings for the Synopsys > GPIO via CREG driver. > > Signed-off-by: Eugeniy Paltsev > --- > .../devicetree/bindings/gpio/snps,creg-gpio.txt| 18 > ++ > 1 file changed, 18 insertions(+) > create mode 100644 Documentation/devicetree/bindings/gpio/snps,creg-gpio.txt > Reviewed-by: Rob Herring ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 03/30] mm: remove CONFIG_HAVE_MEMBLOCK
On Wed, Sep 26, 2018 at 11:32 AM Mike Rapoport wrote:
>
> On Wed, Sep 26, 2018 at 09:58:41AM -0700, Alexander Duyck wrote:
> > On Fri, Sep 14, 2018 at 5:11 AM Mike Rapoport
> > wrote:
> > >
> > > All architecures use memblock for early memory management. There is no
> > > need
> > > for the CONFIG_HAVE_MEMBLOCK configuration option.
> > >
> > > Signed-off-by: Mike Rapoport
> >
> >
> >
> > > diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> > > index 5169205..4ae91fc 100644
> > > --- a/include/linux/memblock.h
> > > +++ b/include/linux/memblock.h
> > > @@ -2,7 +2,6 @@
> > > #define _LINUX_MEMBLOCK_H
> > > #ifdef __KERNEL__
> > >
> > > -#ifdef CONFIG_HAVE_MEMBLOCK
> > > /*
> > > * Logical memory blocks.
> > > *
> > > @@ -460,7 +459,6 @@ static inline phys_addr_t memblock_alloc(phys_addr_t
> > > size, phys_addr_t align)
> > > {
> > > return 0;
> > > }
> > > -#endif /* CONFIG_HAVE_MEMBLOCK */
> > >
> > > #endif /* __KERNEL__ */
> >
> > There was an #else above this section and I believe it and the code
> > after it needs to be stripped as well.
>
> Right, I've already sent the fix [1] and it's in mmots.
>
> [1] https://lkml.org/lkml/2018/9/19/416
>
Are you sure? The patch you reference appears to be for
drivers/of/fdt.c, and the bit I pointed out here is in
include/linux/memblock.h.
- Alex
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: ARC: machine dictionary - ARCompact vs ARCv2
On Tue, Sep 25, 2018 at 4:57 AM Alexey Brodkin wrote: > > Hello, > > While upstreaming ARC bits in OE core I faced one interesting challenge. > > As of today we have 2 binary-incompatible 32-bit ISAs (Instruction Set Arch): > 1. ARCompact (AKA ARCv1) and > 2. ARCv2 > > In Binutils they have 2 separate machine numbers: EM_ARC_COMPACT=93 for > ARCompact, > see [1] and EM_ARC_COMPACT2=195 for ARCv2, see [2]. > > Still we call them both "arc" and so I'm not sure what would be the right way > of handling that mess in OE's machine dictionary. mess is the right word. My preference would be to keep the newer one in OE as the support is new, > > For now I just have separate instances of "arc_machine_dict" for ARCompact [3] > and ARCv2 [4] and depending on what a given OE "machine" includes as > "tune-arcX.inc" > build system uses one or another dictionary entry. > > Even though it works fine it doesn't fit into common dictionary in > meta/lib/oe/elf.py. > > Any suggestions on how ARC machine dictionary might be upstreamed? you can define a separate arch like x32 is for x86_64 arch. but I think PACKAGEQA_EXTRA_MACHDEFFUNCS is a way to hook in such ana > > -Alexey > > [1] > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=include/elf/common.h;h=e194274305663f565c6beee5ec21dbed70cdac46;hb=HEAD#l202 > [2] > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=include/elf/common.h;h=e194274305663f565c6beee5ec21dbed70cdac46;hb=HEAD#l309 > [3] > https://github.com/foss-for-synopsys-dwc-arc-processors/meta-synopsys/blob/083958dedbd60c022432a17e952638a41e37c3dc/conf/machine/include/tune-arcompact.inc#L25 > [4] > https://github.com/foss-for-synopsys-dwc-arc-processors/meta-synopsys/blob/083958dedbd60c022432a17e952638a41e37c3dc/conf/machine/include/tune-arcv2.inc#L38 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 03/30] mm: remove CONFIG_HAVE_MEMBLOCK
On Wed, Sep 26, 2018 at 05:34:32PM -0700, Alexander Duyck wrote:
> On Wed, Sep 26, 2018 at 11:32 AM Mike Rapoport
> wrote:
> >
> > On Wed, Sep 26, 2018 at 09:58:41AM -0700, Alexander Duyck wrote:
> > > On Fri, Sep 14, 2018 at 5:11 AM Mike Rapoport
> > > wrote:
> > > >
> > > > All architecures use memblock for early memory management. There is no
> > > > need
> > > > for the CONFIG_HAVE_MEMBLOCK configuration option.
> > > >
> > > > Signed-off-by: Mike Rapoport
> > >
> > >
> > >
> > > > diff --git a/include/linux/memblock.h b/include/linux/memblock.h
> > > > index 5169205..4ae91fc 100644
> > > > --- a/include/linux/memblock.h
> > > > +++ b/include/linux/memblock.h
> > > > @@ -2,7 +2,6 @@
> > > > #define _LINUX_MEMBLOCK_H
> > > > #ifdef __KERNEL__
> > > >
> > > > -#ifdef CONFIG_HAVE_MEMBLOCK
> > > > /*
> > > > * Logical memory blocks.
> > > > *
> > > > @@ -460,7 +459,6 @@ static inline phys_addr_t
> > > > memblock_alloc(phys_addr_t size, phys_addr_t align)
> > > > {
> > > > return 0;
> > > > }
> > > > -#endif /* CONFIG_HAVE_MEMBLOCK */
> > > >
> > > > #endif /* __KERNEL__ */
> > >
> > > There was an #else above this section and I believe it and the code
> > > after it needs to be stripped as well.
> >
> > Right, I've already sent the fix [1] and it's in mmots.
> >
> > [1] https://lkml.org/lkml/2018/9/19/416
> >
>
> Are you sure? The patch you reference appears to be for
> drivers/of/fdt.c, and the bit I pointed out here is in
> include/linux/memblock.h.
Ah, sorry. You are right, will fix. Thanks for spotting it!
> - Alex
>
--
Sincerely yours,
Mike.
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
