Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753838AbdHXVhK (ORCPT ); Thu, 24 Aug 2017 17:37:10 -0400 Received: from mail-ua0-f173.google.com ([209.85.217.173]:34779 "EHLO mail-ua0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753457AbdHXVhI (ORCPT ); Thu, 24 Aug 2017 17:37:08 -0400 X-Google-Smtp-Source: ADKCNb6f/KT9hDW1s4/9whR0PngPnTiL9Ze6Iw7pz/Vd3v++2BujbJ1fDBiDBtEKVNUC8Uewydz83TDQYkVMZ8ykz78= MIME-Version: 1.0 In-Reply-To: References: <1503418256-5215-1-git-send-email-oleksandrs@mellanox.com> From: Rick Altherr Date: Thu, 24 Aug 2017 14:37:06 -0700 Message-ID: Subject: Re: [patch v6 0/3] JTAG driver introduction To: Linus Walleij Cc: Oleksandr Shamray , "devicetree@vger.kernel.org" , jiri@resnulli.us, Arnd Bergmann , system-sw-low-level@mellanox.com, Greg KH , OpenBMC Maillist , "linux-kernel@vger.kernel.org" , openocd-devel-owner@lists.sourceforge.net, mec@shout.net, Rob Herring , "linux-serial@vger.kernel.org" , vadimp@maellanox.com, Tobias Klauser , "linux-api@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1546 Lines: 41 On Thu, Aug 24, 2017 at 2:07 PM, Linus Walleij wrote: > On Tue, Aug 22, 2017 at 6:10 PM, Oleksandr Shamray > wrote: > >> SoC which are not equipped with JTAG master interface, can be built >> on top of JTAG core driver infrastructure, by applying bit-banging of >> TDI, TDO, TCK and TMS pins within the hardware specific driver. > > I guess you mean it should then use GPIO lines for bit-banging? > > I was wondering about how some JTAG clients like openOCD does > this in some cases. > Many common uses of OpenOCD leverage USB devices, such as FTDI FT232R, that have a command queue for bitbanging operations. Managing these via libusb is ugly but platform-agnostic. > In my worst nightmare they export GPIO lines using > the horrid ABI in /sys/gpio/* > https://sourceforge.net/p/openocd/code/ci/v0.10.0/tree/src/jtag/drivers/sysfsgpio.c While that is certainly horrible (and slow), mapping in the GPIO registers via /dev/mem strikes me as worse: https://sourceforge.net/p/openocd/code/ci/v0.10.0/tree/src/jtag/drivers/bcm2835gpio.c > In best case they use the GPIO character device or even > libgpiod. > > But having a JTAG abstraction inside the kernel that can > grab a few lines for JTAG defined in a device tree, ACPI DSDT > or similar makes sense too, as it abstracts the hardware so the > JTAG client can then just open whatever /dev/jtag0 is on the machine > and go ahead without having to bother about what GPIO lines > are connected exactly where. > > Yours, > Linus Walleij