* [PATCH V7 0/4] phy: USB and PCIe phy drivers for Qcom chipsets
From: Vivek Gautam @ 2017-04-05 12:32 UTC (permalink / raw)
To: kishon, robh+dt
Cc: mark.rutland, devicetree, linux-arm-msm, linux-usb, sboyd,
linux-kernel, bjorn.andersson, srinivas.kandagatla, Vivek Gautam,
linux-arm-kernel
This patch series adds couple of PHY drivers for Qualcomm chipsets.
a) qcom-qusb2 phy driver: that provides High Speed USB functionality.
b) qcom-qmp phy driver: that is a combo phy providing support for
USB3, PCIe, UFS and few other controllers.
The patches are based on next branch of linux-phy tree.
These patches have been tested on Dragon board db820c hardware with
required set of dt patches and the patches to get rpm up on msm8996.
Couple of other patches [1, 2] fixing DMA config for XHCI are also
pulled in for testing.
A branch based on torvald's master is available in github [3].
Changes since v6:
- Rebased on phy/next and *not* including phy grouping series[4].
- qusb2-phy: addressed Stephen's comment.
- Dropped pm8994_s2 corner regulator from QUSB2 phy bindings.
- qmp-phy: none on functionality side.
Changes since v5:
- Addressed review comments from Bjorn:
- Removed instances of readl/wirtel_relaxed calls from the drivers.
Instead, using simple readl/writel. Inserting a readl after a writel
to ensure the write is through to the device.
- Replaced regulator handling with regulator_bulk_** apis. This helps
in cutting down a lot of regulator handling code.
- Fixed minor return statements.
Changes since v4:
- Addressed comment to add child nodes for qmp phy driver. Each phy lane
now has a separate child node under the main qmp node.
- Modified the clock and reset initialization and enable methods.
Different phys - pcie, usb and later ufs, have varying number of clocks
and resets that are mandatory. So adding provision for clocks and reset
lists helps in requesting all mandatory resources for individual phys
and handle their failure cases accordingly.
Changes since v3:
- Addressed review comments given by Rob and Stephen for qusb2 phy
and qmp phy bindings respectively.
- Addressed review comments given by Stephen and Bjorn for qmp phy driver.
Changes since v2:
- Addressed review comments given by Rob and Stephen for bindings.
- Addressed the review comments given by Stephen for the qusb2 and qmp
phy drivers.
Changes since v1:
- Moved device tree binding documentation to separate patches, as suggested
by Rob.
- Addressed review comment regarding qfprom accesses by qusb2 phy driver,
given by Rob.
- Addressed review comments from Kishon.
- Addressed review comments from Srinivas for QMP phy driver.
- Addressed kbuild warning.
Please see individual patches for detailed changelogs.
[1] https://patchwork.kernel.org/patch/9567767/
[2] https://patchwork.kernel.org/patch/9567779/
[3] https://github.com/vivekgautam1/linux/tree/linux-v4.11-rc5-qmp-phy-db820c
[4] https://lkml.org/lkml/2017/3/20/407
Vivek Gautam (4):
dt-bindings: phy: Add support for QUSB2 phy
phy: qcom-qusb2: New driver for QUSB2 PHY on Qcom chips
dt-bindings: phy: Add support for QMP phy
phy: qcom-qmp: new qmp phy driver for qcom-chipsets
.../devicetree/bindings/phy/qcom-qmp-phy.txt | 106 ++
.../devicetree/bindings/phy/qcom-qusb2-phy.txt | 43 +
drivers/phy/Kconfig | 18 +
drivers/phy/Makefile | 2 +
drivers/phy/phy-qcom-qmp.c | 1153 ++++++++++++++++++++
drivers/phy/phy-qcom-qusb2.c | 491 +++++++++
6 files changed, 1813 insertions(+)
create mode 100644 Documentation/devicetree/bindings/phy/qcom-qmp-phy.txt
create mode 100644 Documentation/devicetree/bindings/phy/qcom-qusb2-phy.txt
create mode 100644 drivers/phy/phy-qcom-qmp.c
create mode 100644 drivers/phy/phy-qcom-qusb2.c
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v2] i2c/muxes/i2c-mux-ltc4306: LTC4306 and LTC4305 I2C multiplexer/switch
From: Michael Hennerich @ 2017-04-05 12:21 UTC (permalink / raw)
To: Peter Rosin, wsa-z923LK4zBo2bacvFa/9K2g,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <b5838bae-8108-1a0e-5234-d14cb5e95e52-koto5C5qi+TLoDKTGw+V6w@public.gmane.org>
On 04.04.2017 11:28, Peter Rosin wrote:
> *snip* *snip*
>
>>>> +static int ltc4306_gpio_get(struct gpio_chip *chip, unsigned int offset)
>>>> +{
>>>> + struct ltc4306 *data = gpiochip_get_data(chip);
>>>> + int ret = 0;
>>>> +
>>>> + if (gpiochip_line_is_open_drain(chip, offset) ||
>>>> + (data->regs[LTC_REG_MODE] & BIT(7 - offset))) {
>>>
>>> I wonder about this open-coded register cache. So, gpio people, is there
>>> a guarantee from gpiolib that only one gpio_chip operation is in flight
>>> concurrently? Because I don't see any evidence of that. With that in
>>> mind, I think some locking is needed?
>>
>> I thought there is a per chip mutex in the gpiolib. But I can't find
>> anything like this either. Since these two gpios can be used from
>> different internal or external users. The locking seem to be needed.
>>
>> This gets us back to the regmap option. I did a quick grep, and 9 out of
>> 205 drivers using regmap i2c, also use i2c_smbus... concurrently.
>>
>> grep -Rl regmap_init_i2c ./drivers | xargs grep -l i2c_smbus_ | grep "\.c"
>>
>> Mostly to work around non uniform transfer layouts.
>
> I see three options.
>
> 1. Go with regmap and convert to mux-locked. Then the unlocked i2c-xfer
> becomes an ordinary i2c-xfer (or smbus, whatever). This will result in
> the cleanest code.
ok - you convinced me.
>
> 2. Go with regmap and stay parent-locked. Then hook into the regmap
> locking as is done in one of the drivers that have worked around similar
> problems with regmap and parent-locked i2c-mux interactions:
>
> drivers/media/dvb-frontends/rtl2830.c
> drivers/media/dvb-frontends/m88ds3103.c
>
> This will probably work, but you'd need to add a number of extra helper
> functions.
>
> 3. Exclude register 3 from regmap and only use regmap for the other
> registers. This will be a bit ugly and ad-hoc, will need clear comments
> on what is going on and why it is safe etc. And I want to see it before
> I accept it. And it might not be my call to begin with, because TBH, it
> sounds a bit disgusting...
>
>> I'll check with Mark Brown on this topic.
>
> Ok, might be a good idea...
>
>>>> +
>>>> +add_adapter_failed:
>>>> + i2c_mux_del_adapters(muxc);
>>>> +gpio_default:
>>>> + gpiod_direction_input(data->en_gpio);
>>>
>>> This was actually not what I had in mind when I asked about it in v1, and
>>> this looks a bit strange. You have no way of knowing if the pin was
>>> configured as input when probe was called, and I don't see code like this
>>> all over the place. Maybe it's is ok to not disable the chip over
>>> suspend/resume, I was just asking because it looked a bit strange to grab
>>> a pin and then forget about it. Now that I think about it some more, it's
>>> probably ok to do just that since it is perhaps not possible to make the
>>> chip draw less power by deasserting enable, but what do I know?
>>
>> GPIOs are assumed by default inputs. So if you want to undo the actions
>> in probe. The logical consequence is to move them back to inputs, and
>> let the external PULL-UP or PULL-DOWN on the ENABLE decide what happens.
>> I would also prefer to leave it enabled, so that the GPIOs can retain
>
> My point is that I do not see any probe functions undoing gpio configs.
> Why bother in this case? Or are other probe functions really doing this?
> I actually didn't check, but I haven't stumbled over it previously and
> at least think I would have noticed...
>
>> it's last state. Well I think the device draws a bit less power when
>> disabled. But we don't support runtime PM anyways.
>
> It might not be safe to reset the gpio pins over a suspend/resume depending
> on what they are used for, so it is probably a bad idea to go there. Sorry
> for bringing the whole issue up and muddying the waters...
I restore the original implementation and also pulse the ENABLE low so
we're always doing a clean reset.
I'll send a new patch shortly.
Thanks!
--
Greetings,
Michael
--
Analog Devices GmbH Otl-Aicher Strasse 60-64 80807 München
Sitz der Gesellschaft München, Registergericht München HRB 40368,
Geschäftsführer: Peter Kolberg, Ali Raza Husain, Eileen Wynne
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 3/3] clk: vc5: Add support for IDT VersaClock 5P49V5935
From: Geert Uytterhoeven @ 2017-04-05 12:20 UTC (permalink / raw)
To: Alexey Firago
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Marek Vasut,
linux-clk, devicetree@vger.kernel.org
In-Reply-To: <1491392819-698-4-git-send-email-alexey_firago@mentor.com>
On Wed, Apr 5, 2017 at 1:46 PM, Alexey Firago <alexey_firago@mentor.com> wrote:
> Update IDT VersaClock 5 driver to support 5P49V5935. This chip has
> two clock inputs (internal XTAL or external CLKIN), four fractional
> dividers (FODs) and five clock outputs (four universal clock outputs
> and one reference clock output at OUT0_SELB_I2C).
>
> Current driver supports up to 2 FODs and up to 3 clock outputs. This
> patch sets max number of supported FODs to 4 and max number of supported
> clock outputs to 5.
>
> Signed-off-by: Alexey Firago <alexey_firago@mentor.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH V8 1/6] LIBIO: Introduce a generic PIO mapping method
From: zhichang.yuan @ 2017-04-05 12:18 UTC (permalink / raw)
To: kbuild test robot, fengguang.wu
Cc: zhichang.yuan, kbuild-all, catalin.marinas, will.deacon, robh+dt,
frowand.list, bhelgaas, rafael, arnd, linux-arm-kernel,
mark.rutland, brian.starkey, olof, lorenzo.pieralisi, benh,
linux-kernel, linux-acpi, linuxarm, devicetree, linux-pci,
minyard, zourongrong, john.garry, gabriele.paoloni, xuwei5
In-Reply-To: <201704011328.1YdgEHnc%fengguang.wu@intel.com>
Hi,
Thanks for your report!
I am sorry for that!
This issue was caused by missing the '#include <linux/logic_pio.h>' in
logic_pio.c for some architectures where the 'asm-generic/io.h' wasn't been
included.
Will be fixed in the next V9.
Apologized for this!
-Zhichang
On 04/01/2017 01:58 PM, kbuild test robot wrote:
> Hi zhichang.yuan,
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on v4.11-rc4 next-20170331]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
>
> url: https://github.com/0day-ci/linux/commits/zhichang-yuan/LIBIO-Introduce-a-generic-PIO-mapping-method/20170401-104801
> config: alpha-allyesconfig (attached as .config)
> compiler: alpha-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
> reproduce:
> wget https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
> chmod +x ~/bin/make.cross
> # save the attached .config to linux build tree
> make.cross ARCH=alpha
>
> All error/warnings (new ones prefixed by >>):
>
>>> lib/logic_pio.c:32:50: error: 'PIO_MAX_SECT' undeclared here (not in a function)
> static struct logic_pio_root logic_pio_root_list[PIO_MAX_SECT] = {
> ^~~~~~~~~~~~
>>> lib/logic_pio.c:39:3: error: 'PIO_CPU_MMIO' undeclared here (not in a function)
> [PIO_CPU_MMIO ... PIO_INDIRECT - 1] = {
> ^~~~~~~~~~~~
>>> lib/logic_pio.c:39:20: error: 'PIO_INDIRECT' undeclared here (not in a function)
> [PIO_CPU_MMIO ... PIO_INDIRECT - 1] = {
> ^~~~~~~~~~~~
>>> lib/logic_pio.c:39:3: error: array index in initializer not of integer type
> [PIO_CPU_MMIO ... PIO_INDIRECT - 1] = {
> ^~~~~~~~~~~~
> lib/logic_pio.c:39:3: note: (near initialization for 'logic_pio_root_list')
>>> lib/logic_pio.c:40:3: error: field name not in record or union initializer
> .sec_head = LIST_HEAD_INIT(logic_pio_root_list[PIO_CPU_MMIO].sec_head),
> ^
> lib/logic_pio.c:40:3: note: (near initialization for 'logic_pio_root_list')
> lib/logic_pio.c:41:3: error: field name not in record or union initializer
> .sec_min = PIO_SECT_MIN(PIO_CPU_MMIO),
> ^
> lib/logic_pio.c:41:3: note: (near initialization for 'logic_pio_root_list')
>>> lib/logic_pio.c:41:14: error: implicit declaration of function 'PIO_SECT_MIN' [-Werror=implicit-function-declaration]
> .sec_min = PIO_SECT_MIN(PIO_CPU_MMIO),
> ^~~~~~~~~~~~
> lib/logic_pio.c:42:3: error: field name not in record or union initializer
> .sec_max = PIO_SECT_MAX(PIO_INDIRECT - 1),
> ^
> lib/logic_pio.c:42:3: note: (near initialization for 'logic_pio_root_list')
>>> lib/logic_pio.c:42:14: error: implicit declaration of function 'PIO_SECT_MAX' [-Werror=implicit-function-declaration]
> .sec_max = PIO_SECT_MAX(PIO_INDIRECT - 1),
> ^~~~~~~~~~~~
> lib/logic_pio.c:46:3: error: array index in initializer not of integer type
> [PIO_INDIRECT] = {
> ^~~~~~~~~~~~
> lib/logic_pio.c:46:3: note: (near initialization for 'logic_pio_root_list')
> lib/logic_pio.c:47:3: error: field name not in record or union initializer
> .sec_head = LIST_HEAD_INIT(logic_pio_root_list[PIO_INDIRECT].sec_head),
> ^
> lib/logic_pio.c:47:3: note: (near initialization for 'logic_pio_root_list')
> lib/logic_pio.c:48:3: error: field name not in record or union initializer
> .sec_min = PIO_SECT_MIN(PIO_INDIRECT),
> ^
> lib/logic_pio.c:48:3: note: (near initialization for 'logic_pio_root_list')
> lib/logic_pio.c:49:3: error: field name not in record or union initializer
> .sec_max = PIO_SECT_MAX(PIO_INDIRECT),
> ^
> lib/logic_pio.c:49:3: note: (near initialization for 'logic_pio_root_list')
> In file included from include/linux/list.h:8:0,
> from include/linux/kobject.h:20,
> from include/linux/of.h:21,
> from lib/logic_pio.c:18:
> lib/logic_pio.c: In function 'logic_pio_find_range_byaddr':
>>> include/linux/rculist.h:351:49: error: dereferencing pointer to incomplete type 'struct logic_pio_hwaddr'
> for (pos = list_entry_rcu((head)->next, typeof(*pos), member); \
>
> include/linux/kernel.h:852:18: note: in definition of macro 'container_of'
> const typeof( ((type *)0)->member ) *__mptr = (ptr); \
> ^~~~
>>> include/linux/rculist.h:351:13: note: in expansion of macro 'list_entry_rcu'
> for (pos = list_entry_rcu((head)->next, typeof(*pos), member); \
> ^~~~~~~~~~~~~~
>>> lib/logic_pio.c:77:2: note: in expansion of macro 'list_for_each_entry_rcu'
> list_for_each_entry_rcu(range, &io_range_list, list) {
> ^~~~~~~~~~~~~~~~~~~~~~~
> include/linux/kernel.h:852:48: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
> const typeof( ((type *)0)->member ) *__mptr = (ptr); \
> ^
>>> include/linux/rculist.h:277:2: note: in expansion of macro 'container_of'
> container_of(lockless_dereference(ptr), type, member)
> ^~~~~~~~~~~~
>>> include/linux/rculist.h:351:13: note: in expansion of macro 'list_entry_rcu'
> for (pos = list_entry_rcu((head)->next, typeof(*pos), member); \
> ^~~~~~~~~~~~~~
>>> lib/logic_pio.c:77:2: note: in expansion of macro 'list_for_each_entry_rcu'
> list_for_each_entry_rcu(range, &io_range_list, list) {
> ^~~~~~~~~~~~~~~~~~~~~~~
>>> include/linux/kernel.h:852:48: warning: initialization makes pointer from integer without a cast [-Wint-conversion]
> const typeof( ((type *)0)->member ) *__mptr = (ptr); \
> ^
>>> include/linux/rculist.h:277:2: note: in expansion of macro 'container_of'
> container_of(lockless_dereference(ptr), type, member)
> ^~~~~~~~~~~~
> include/linux/rculist.h:353:9: note: in expansion of macro 'list_entry_rcu'
> pos = list_entry_rcu(pos->member.next, typeof(*pos), member))
> ^~~~~~~~~~~~~~
>>> lib/logic_pio.c:77:2: note: in expansion of macro 'list_for_each_entry_rcu'
> list_for_each_entry_rcu(range, &io_range_list, list) {
> ^~~~~~~~~~~~~~~~~~~~~~~
> lib/logic_pio.c: In function 'logic_pio_alloc_range':
>>> lib/logic_pio.c:109:19: error: dereferencing pointer to incomplete type 'struct logic_pio_root'
> idle_start = root->sec_min;
> ^~
> In file included from include/linux/list.h:8:0,
> from include/linux/kobject.h:20,
> from include/linux/of.h:21,
> from lib/logic_pio.c:18:
>>> include/linux/rculist.h:351:49: error: dereferencing pointer to incomplete type 'struct logic_pio_sect'
> for (pos = list_entry_rcu((head)->next, typeof(*pos), member); \
>
> include/linux/kernel.h:852:18: note: in definition of macro 'container_of'
> const typeof( ((type *)0)->member ) *__mptr = (ptr); \
> ^~~~
>>> include/linux/rculist.h:351:13: note: in expansion of macro 'list_entry_rcu'
> for (pos = list_entry_rcu((head)->next, typeof(*pos), member); \
> ^~~~~~~~~~~~~~
> lib/logic_pio.c:111:2: note: in expansion of macro 'list_for_each_entry_rcu'
> list_for_each_entry_rcu(entry, &root->sec_head, list) {
> ^~~~~~~~~~~~~~~~~~~~~~~
>>> include/linux/kernel.h:852:48: warning: initialization makes pointer from integer without a cast [-Wint-conversion]
> const typeof( ((type *)0)->member ) *__mptr = (ptr); \
> ^
>
> vim +/PIO_MAX_SECT +32 lib/logic_pio.c
>
> 12 * GNU General Public License for more details.
> 13 *
> 14 * You should have received a copy of the GNU General Public License
> 15 * along with this program. If not, see <http://www.gnu.org/licenses/>.
> 16 */
> 17
> > 18 #include <linux/of.h>
> 19 #include <linux/io.h>
> 20 #include <linux/mm.h>
> 21 #include <linux/rculist.h>
> 22 #include <linux/sizes.h>
> 23 #include <linux/slab.h>
> 24
> 25 /* The unique hardware address list. */
> 26 static LIST_HEAD(io_range_list);
> 27 static DEFINE_MUTEX(io_range_mutex);
> 28
> 29 /*
> 30 * These are the lists for PIO. The highest PIO_SECT_BITS of PIO is the index.
> 31 */
> > 32 static struct logic_pio_root logic_pio_root_list[PIO_MAX_SECT] = {
> 33 #ifdef CONFIG_INDIRECT_PIO
> 34 /*
> 35 * At this moment, assign all the other logic PIO space to MMIO.
> 36 * If more elements added, please adjust the ending index and .sec_max;
> 37 * Please keep MMIO element started from index ZERO.
> 38 */
> > 39 [PIO_CPU_MMIO ... PIO_INDIRECT - 1] = {
> > 40 .sec_head = LIST_HEAD_INIT(logic_pio_root_list[PIO_CPU_MMIO].sec_head),
> > 41 .sec_min = PIO_SECT_MIN(PIO_CPU_MMIO),
> > 42 .sec_max = PIO_SECT_MAX(PIO_INDIRECT - 1),
> 43 },
> 44
> 45 /* The last element */
> 46 [PIO_INDIRECT] = {
> 47 .sec_head = LIST_HEAD_INIT(logic_pio_root_list[PIO_INDIRECT].sec_head),
> 48 .sec_min = PIO_SECT_MIN(PIO_INDIRECT),
> 49 .sec_max = PIO_SECT_MAX(PIO_INDIRECT),
> 50 },
> 51 #else
> 52 [PIO_CPU_MMIO] = {
> 53 .sec_head = LIST_HEAD_INIT(logic_pio_root_list[PIO_CPU_MMIO].sec_head),
> 54 .sec_min = PIO_SECT_MIN(PIO_CPU_MMIO),
> 55 .sec_max = PIO_SECT_MAX(PIO_CPU_MMIO),
> 56 },
> 57
> 58 #endif
> 59 };
> 60
> 61 /*
> 62 * Search a io_range registered which match the fwnode and addr.
> 63 *
> 64 * @fwnode: the host fwnode which must be valid;
> 65 * @start: the start hardware address of this search;
> 66 * @end: the end hardware address of this search. can be equal to @start;
> 67 *
> 68 * return NULL when there is no matched node; IS_ERR() means ERROR;
> 69 * valid virtual address represent a matched node was found.
> 70 */
> 71 static struct logic_pio_hwaddr *
> 72 logic_pio_find_range_byaddr(struct fwnode_handle *fwnode,
> 73 resource_size_t start, resource_size_t end)
> 74 {
> 75 struct logic_pio_hwaddr *range;
> 76
> > 77 list_for_each_entry_rcu(range, &io_range_list, list) {
> 78 if (!range->pio_peer) {
> 79 pr_warn("Invalid cpu addr node(%pa) in list!\n",
> 80 &range->hw_start);
> 81 continue;
> 82 }
> 83 if (range->fwnode != fwnode)
> 84 continue;
> 85 /* without any overlap with current range */
> 86 if (start >= range->hw_start + range->size ||
> 87 end < range->hw_start)
> 88 continue;
> 89 /* overlap is not supported now. */
> 90 if (start < range->hw_start ||
> 91 end >= range->hw_start + range->size)
> 92 return ERR_PTR(-EBUSY);
> 93 /* had been registered. */
> 94 return range;
> 95 }
> 96
> 97 return NULL;
> 98 }
> 99
> 100
> 101 static int logic_pio_alloc_range(struct logic_pio_root *root,
> 102 resource_size_t size, unsigned long align,
> 103 struct list_head **prev, resource_size_t *pio_alloc)
> 104 {
> 105 struct logic_pio_sect *entry;
> 106 resource_size_t tmp_start;
> 107 resource_size_t idle_start, idle_end;
> 108
> > 109 idle_start = root->sec_min;
> 110 *prev = &root->sec_head;
> 111 list_for_each_entry_rcu(entry, &root->sec_head, list) {
> 112 if (!entry->hwpeer ||
> 113 idle_start > entry->io_start) {
> 114 WARN(1, "skip an invalid io range during traversal!\n");
> 115 goto nextentry;
> 116 }
> 117 /* set the end edge. */
> 118 if (idle_start == entry->io_start) {
> 119 struct logic_pio_sect *next;
> 120
> 121 idle_start = entry->io_start + entry->hwpeer->size;
> > 122 next = list_next_or_null_rcu(&root->sec_head,
> > 123 &entry->list, struct logic_pio_sect, list);
> 124 if (next) {
> 125 entry = next;
> 126 } else {
> 127 *prev = &entry->list;
> 128 break;
> 129 }
> 130 }
> 131 idle_end = entry->io_start - 1;
> 132
> 133 /* contiguous range... */
> 134 if (idle_start > idle_end)
> 135 goto nextentry;
> 136
> 137 tmp_start = idle_start;
> 138 idle_start = ALIGN(idle_start, align);
> 139 if (idle_start >= tmp_start &&
> 140 idle_start + size <= idle_end) {
> 141 *prev = &entry->list;
> 142 *pio_alloc = idle_start;
> 143 return 0;
> 144 }
> 145
> 146 nextentry:
> 147 idle_start = entry->io_start + entry->hwpeer->size;
> 148 *prev = &entry->list;
> 149 }
> 150 /* check the last free gap... */
> 151 idle_end = root->sec_max;
> 152
> 153 tmp_start = idle_start;
> 154 idle_start = ALIGN(idle_start, align);
> 155 if (idle_start >= tmp_start &&
> 156 idle_start + size <= idle_end) {
> 157 *pio_alloc = idle_start;
> 158 return 0;
> 159 }
> 160
> 161 return -EBUSY;
> 162 }
> 163
> 164 /*
> 165 * register a io range node in the io range list.
> 166 *
> 167 * @newrange: pointer to the io range to be registered.
> 168 *
> 169 * return 'newrange' when success, ERR_VALUE() is for failures.
> 170 * specially, return a valid pointer which is not equal to 'newrange' when
> 171 * the io range had been registered before.
> 172 */
> 173 struct logic_pio_hwaddr
> 174 *logic_pio_register_range(struct logic_pio_hwaddr *newrange,
> 175 unsigned long align)
> 176 {
> 177 struct logic_pio_hwaddr *range;
> 178 struct logic_pio_sect *newsect;
> 179 resource_size_t pio_alloc;
> 180 struct list_head *prev, *hwprev;
> 181 unsigned long sect_id;
> 182 int err;
> 183
> 184 if (!newrange || !newrange->fwnode || !newrange->size)
> 185 return ERR_PTR(-EINVAL);
> 186
> 187 sect_id = newrange->flags;
> 188 if (sect_id >= PIO_MAX_SECT)
> 189 return ERR_PTR(-EINVAL);
> 190
> 191 mutex_lock(&io_range_mutex);
> 192 range = logic_pio_find_range_byaddr(newrange->fwnode,
> 193 newrange->hw_start,
> 194 newrange->hw_start + newrange->size - 1);
> 195 if (range) {
> 196 if (!IS_ERR(range))
> 197 pr_info("the request IO range had been registered!\n");
> 198 else
> 199 pr_err("registering IO[%pa - sz%pa) got failed!\n",
> 200 &newrange->hw_start, &newrange->size);
> 201 mutex_unlock(&io_range_mutex);
> 202 return range;
> 203 }
> 204
> 205 err = logic_pio_alloc_range(&logic_pio_root_list[sect_id],
> 206 newrange->size, align, &prev, &pio_alloc);
> 207 if (err) {
> 208 pr_err("can't find free %pa logical IO range!\n",
> 209 &newrange->size);
> 210 goto exitproc;
> 211 }
> 212
> 213 if (prev == &logic_pio_root_list[sect_id].sec_head) {
> 214 hwprev = &io_range_list;
> 215 } else {
> > 216 newsect = to_pio_sect(prev);
> > 217 hwprev = &newsect->hwpeer->list;
> 218 }
> 219
> 220 newsect = kzalloc(sizeof(*newsect), GFP_KERNEL);
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
>
^ permalink raw reply
* Re: [PATCH v4 8/8] ARM: sun8i: sina33: add highest OPP of CPUs
From: Maxime Ripard @ 2017-04-05 12:17 UTC (permalink / raw)
To: Quentin Schulz
Cc: dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
wens-jdAy2FN1RRM, lee.jones-QSEj5FYQhm4dnm+yROfE0A,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, jic23-DgEjT+Ai2ygdnm+yROfE0A,
knaack.h-Mmb7MZpHnFY, lars-Qo5EllUWu/uELgA04lAiVw,
pmeerw-jW+XmwGofnusTnJN9+BGXg,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-input-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, icenowy-ymACFijhrKM
In-Reply-To: <20170405090634.4649-9-quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 631 bytes --]
On Wed, Apr 05, 2017 at 11:06:34AM +0200, Quentin Schulz wrote:
> The A33 supports 1.1GHz and 1.2GHz frequencies at 1.32V and the Sinlinx
> SinA33 has its cpu-supply property set in the cpu DT node.
>
> Therefore, CPUfreq knows how to handle the regulator in charge of the
> CPU and can adjust its voltage to match the OPP.
>
> Add these two CPU frequencies to the CPU OPP table of the Sinlinx
> SinA33.
>
> Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v4 7/8] ARM: sun8i: a33: Add devfreq-based GPU cooling
From: Maxime Ripard @ 2017-04-05 12:16 UTC (permalink / raw)
To: Quentin Schulz
Cc: dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
wens-jdAy2FN1RRM, lee.jones-QSEj5FYQhm4dnm+yROfE0A,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, jic23-DgEjT+Ai2ygdnm+yROfE0A,
knaack.h-Mmb7MZpHnFY, lars-Qo5EllUWu/uELgA04lAiVw,
pmeerw-jW+XmwGofnusTnJN9+BGXg,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-input-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, icenowy-ymACFijhrKM
In-Reply-To: <20170405090634.4649-8-quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 535 bytes --]
On Wed, Apr 05, 2017 at 11:06:33AM +0200, Quentin Schulz wrote:
> From: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
>
> This adds GPU thermal throttling for the Allwinner A33.
>
> Signed-off-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v2 1/3] clk: vc5: Add structure to describe particular chip features
From: Geert Uytterhoeven @ 2017-04-05 12:15 UTC (permalink / raw)
To: Alexey Firago
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Marek Vasut,
linux-clk, devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1491392819-698-2-git-send-email-alexey_firago-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
Hi Alexey,
On Wed, Apr 5, 2017 at 1:46 PM, Alexey Firago <alexey_firago-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org> wrote:
> Introduce vc5_chip_info structure to describe features of a particular
> VC5 chip (id, number of FODs, number of outputs, flags).
> For now flags are only used to indicate if chip has internal XTAL.
> vc5_chip_info is set on probe from the matched of_device_id->data.
>
> Also add defines to specify maximum number of FODs and clock outputs
> supported by the driver.
>
> With these changes it should be easier to extend driver to support
> more VC5 models.
>
> Signed-off-by: Alexey Firago <alexey_firago-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
Thanks for your patch!
Reviewed-by: Geert Uytterhoeven <geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ@public.gmane.org>
> --- a/drivers/clk/clk-versaclock5.c
> +++ b/drivers/clk/clk-versaclock5.c
> @@ -113,12 +113,30 @@
> #define VC5_MUX_IN_XIN BIT(0)
> #define VC5_MUX_IN_CLKIN BIT(1)
>
> +/* Maximum number of clk_out supported by this driver */
> +#define VC5_MAX_CLK_OUT_NUM 3
> +
> +/* Maximum number of FODs supported by this driver */
> +#define VC5_MAX_FOD_NUM 2
> +
> +/* flags to describe chip features */
> +/* chip has built-in oscilator */
> +#define VC5_HAS_INTERNAL_XTAL BIT(0)
VC5_HAS_INTERNAL_OSC?
> +
> /* Supported IDT VC5 models. */
> enum vc5_model {
> IDT_VC5_5P49V5923,
> IDT_VC5_5P49V5933,
> };
>
> +/* Structure to describe features of a particular VC5 model */
> +struct vc5_chip_info {
> + const enum vc5_model model;
> + const int clk_fod_cnt;
> + const int clk_out_cnt;
const unsigned int (both)
> + u32 flags;
> +};
> +
> struct vc5_driver_data;
>
> struct vc5_hw_data {
> @@ -132,15 +150,15 @@ struct vc5_hw_data {
> struct vc5_driver_data {
> struct i2c_client *client;
> struct regmap *regmap;
> - enum vc5_model model;
> + struct vc5_chip_info *chip_info;
const struct vc5_chip_info *chip_info;
> @@ -591,7 +609,7 @@ static int vc5_probe(struct i2c_client *client,
> struct vc5_driver_data *vc5;
> struct clk_init_data init;
> const char *parent_names[2];
> - unsigned int n, idx;
> + unsigned int n, idx = 0;
> int ret;
>
> vc5 = devm_kzalloc(&client->dev, sizeof(*vc5), GFP_KERNEL);
> @@ -600,7 +618,12 @@ static int vc5_probe(struct i2c_client *client,
>
> i2c_set_clientdata(client, vc5);
> vc5->client = client;
> - vc5->model = (enum vc5_model)of_id->data;
> +
> + vc5->chip_info = (struct vc5_chip_info *)of_id->data;
I think the cast is no longer needed when chip_info becomes const.
BTW, of_id is not really needed if you write it like:
vc5->chip_info = of_device_get_match_data(&client->dev);
> + if (!vc5->chip_info) {
This can't really happen, can it?
> + dev_err(&client->dev, "No device match found\n");
> + return -ENODEV;
> + }
>
> vc5->pin_xin = devm_clk_get(&client->dev, "xin");
> if (PTR_ERR(vc5->pin_xin) == -EPROBE_DEFER)
> @@ -622,8 +645,8 @@ static int vc5_probe(struct i2c_client *client,
> if (!IS_ERR(vc5->pin_xin)) {
> vc5->clk_mux_ins |= VC5_MUX_IN_XIN;
> parent_names[init.num_parents++] = __clk_get_name(vc5->pin_xin);
> - } else if (vc5->model == IDT_VC5_5P49V5933) {
> - /* IDT VC5 5P49V5933 has built-in oscilator. */
> + } else if (vc5->chip_info->flags & VC5_HAS_INTERNAL_XTAL) {
> + /* chip has built-in oscilator. */
The comment is no longer needed when the bit is named VC5_HAS_INTERNAL_OSC :-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4 6/8] ARM: sun8i: a33: add CPU thermal throttling
From: Maxime Ripard @ 2017-04-05 12:13 UTC (permalink / raw)
To: Quentin Schulz
Cc: dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
wens-jdAy2FN1RRM, lee.jones-QSEj5FYQhm4dnm+yROfE0A,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, jic23-DgEjT+Ai2ygdnm+yROfE0A,
knaack.h-Mmb7MZpHnFY, lars-Qo5EllUWu/uELgA04lAiVw,
pmeerw-jW+XmwGofnusTnJN9+BGXg,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-input-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, icenowy-ymACFijhrKM
In-Reply-To: <20170405090634.4649-7-quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2445 bytes --]
On Wed, Apr 05, 2017 at 11:06:32AM +0200, Quentin Schulz wrote:
> This adds CPU thermal throttling for the Allwinner A33. It uses the
> thermal sensor present in the SoC's GPADC.
>
> Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
>
> v3:
> - switched to new phandle because of modified DT node name for the GPADC
> (named THS),
> - got rid of cooling-min-level and cooling-max-level as it's not used in any
> code in the kernel,
>
> v2:
> - updated cooling-max-level to reflect newly added OPPs,
>
> arch/arm/boot/dts/sun8i-a33.dtsi | 45 ++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 45 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
> index 9734e63..b88c107 100644
> --- a/arch/arm/boot/dts/sun8i-a33.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a33.dtsi
> @@ -43,6 +43,7 @@
> */
>
> #include "sun8i-a23-a33.dtsi"
> +#include <dt-bindings/thermal/thermal.h>
>
> / {
> cpu0_opp_table: opp_table0 {
> @@ -127,6 +128,7 @@
> clocks = <&ccu CLK_CPUX>;
> clock-names = "cpu";
> operating-points-v2 = <&cpu0_opp_table>;
> + #cooling-cells = <2>;
> };
>
> cpu@1 {
> @@ -170,6 +172,49 @@
> };
> };
>
> + thermal-zones {
> + cpu_thermal {
> + /* milliseconds */
> + polling-delay-passive = <250>;
> + polling-delay = <1000>;
> + thermal-sensors = <&ths>;
> +
> + cooling-maps {
> + map0 {
> + trip = <&cpu_alert0>;
> + cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> + };
> + map1 {
> + trip = <&cpu_alert1>;
> + cooling-device = <&cpu0 THERMAL_NO_LIMIT THERMAL_NO_LIMIT>;
> + };
> + };
> +
> + trips {
> + cpu_alert0: cpu_alert0 {
> + /* milliCelsius */
> + temperature = <75000>;
> + hysteresis = <2000>;
> + type = "passive";
> + };
> +
> + cpu_alert1: cpu_alert1 {
> + /* milliCelsius */
> + temperature = <90000>;
> + hysteresis = <2000>;
> + type = "hot";
> + };
> +
> + cpu_crit: cpu_crit {
> + /* milliCelsius */
> + temperature = <110000>;
> + hysteresis = <2000>;
> + type = "critical";
> + };
> + };
> + };
> + };
> +
This wasn't sorted properly (thermal is not between mali- and memory
in the alphabetical order). Fixed and applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v4 5/8] ARM: sun8i: a33: add thermal sensor
From: Maxime Ripard @ 2017-04-05 12:12 UTC (permalink / raw)
To: Quentin Schulz
Cc: dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
wens-jdAy2FN1RRM, lee.jones-QSEj5FYQhm4dnm+yROfE0A,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, jic23-DgEjT+Ai2ygdnm+yROfE0A,
knaack.h-Mmb7MZpHnFY, lars-Qo5EllUWu/uELgA04lAiVw,
pmeerw-jW+XmwGofnusTnJN9+BGXg,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-input-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, icenowy-ymACFijhrKM
In-Reply-To: <20170405090634.4649-6-quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1413 bytes --]
Hi,
On Wed, Apr 05, 2017 at 11:06:31AM +0200, Quentin Schulz wrote:
> This adds the DT node for the thermal sensor present in the Allwinner
> A33 GPADC.
>
> Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> ---
>
> v3:
> - switched compatible to allwinner,sun8i-a33-ths,
> - renamed DT node name and label to ths to better match datasheet's name,
>
> arch/arm/boot/dts/sun8i-a33.dtsi | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/arch/arm/boot/dts/sun8i-a33.dtsi
> index 077db22..9734e63 100644
> --- a/arch/arm/boot/dts/sun8i-a33.dtsi
> +++ b/arch/arm/boot/dts/sun8i-a33.dtsi
> @@ -266,6 +266,13 @@
> status = "disabled";
> };
>
> + ths: ths@01c25000 {
> + compatible = "allwinner,sun8i-a33-ths";
> + reg = <0x01c25000 0x100>;
> + #thermal-sensor-cells = <0>;
> + #io-channel-cells = <0>;
> + };
> +
> fe0: display-frontend@01e00000 {
> compatible = "allwinner,sun8i-a33-display-frontend";
> reg = <0x01e00000 0x20000>;
> @@ -376,6 +383,11 @@
> };
> };
> };
> +
> + iio-hwmon {
> + compatible = "iio-hwmon";
> + io-channels = <&ths>;
> + };
This wasn't sorted properly (iio is before soc in the alphabetical order).
Fixed it and applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v4 2/8] dt-bindings: input: touschcreen: remove sun4i documentation
From: Lee Jones @ 2017-04-05 12:11 UTC (permalink / raw)
To: Quentin Schulz
Cc: dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, jic23-DgEjT+Ai2ygdnm+yROfE0A,
knaack.h-Mmb7MZpHnFY, lars-Qo5EllUWu/uELgA04lAiVw,
pmeerw-jW+XmwGofnusTnJN9+BGXg,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-input-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, icenowy-ymACFijhrKM
In-Reply-To: <20170405090634.4649-3-quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Wed, 05 Apr 2017, Quentin Schulz wrote:
> This patch removes the sun4i touchscreen controller binding
> documentation since it has been merged with the sun4i GPADC binding
> documentation.
>
> Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> Acked-by: Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
>
> v4:
> - correct patch title,
>
> .../bindings/input/touchscreen/sun4i.txt | 38 ----------------------
> 1 file changed, 38 deletions(-)
> delete mode 100644 Documentation/devicetree/bindings/input/touchscreen/sun4i.txt
Applied, thanks.
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt b/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt
> deleted file mode 100644
> index 89abecd..0000000
> --- a/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt
> +++ /dev/null
> @@ -1,38 +0,0 @@
> -sun4i resistive touchscreen controller
> ---------------------------------------
> -
> -Required properties:
> - - compatible: "allwinner,sun4i-a10-ts", "allwinner,sun5i-a13-ts" or
> - "allwinner,sun6i-a31-ts"
> - - reg: mmio address range of the chip
> - - interrupts: interrupt to which the chip is connected
> - - #thermal-sensor-cells: shall be 0
> -
> -Optional properties:
> - - allwinner,ts-attached : boolean indicating that an actual touchscreen
> - is attached to the controller
> - - allwinner,tp-sensitive-adjust : integer (4 bits)
> - adjust sensitivity of pen down detection
> - between 0 (least sensitive) and 15
> - (defaults to 15)
> - - allwinner,filter-type : integer (2 bits)
> - select median and averaging filter
> - samples used for median / averaging filter
> - 0: 4/2
> - 1: 5/3
> - 2: 8/4
> - 3: 16/8
> - (defaults to 1)
> -
> -Example:
> -
> - rtp: rtp@01c25000 {
> - compatible = "allwinner,sun4i-a10-ts";
> - reg = <0x01c25000 0x100>;
> - interrupts = <29>;
> - allwinner,ts-attached;
> - #thermal-sensor-cells = <0>;
> - /* sensitive/noisy touch panel */
> - allwinner,tp-sensitive-adjust = <0>;
> - allwinner,filter-type = <3>;
> - };
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH v4 1/8] dt-bindings: mfd: add A33 GPADC binding
From: Lee Jones @ 2017-04-05 12:11 UTC (permalink / raw)
To: Quentin Schulz
Cc: dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8, wens-jdAy2FN1RRM,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, jic23-DgEjT+Ai2ygdnm+yROfE0A,
knaack.h-Mmb7MZpHnFY, lars-Qo5EllUWu/uELgA04lAiVw,
pmeerw-jW+XmwGofnusTnJN9+BGXg,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-input-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, icenowy-ymACFijhrKM
In-Reply-To: <20170405090634.4649-2-quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
On Wed, 05 Apr 2017, Quentin Schulz wrote:
> This patch adds documentation for the A33 GPADC binding.
>
> Signed-off-by: Quentin Schulz <quentin.schulz-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
> Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> ---
> v4:
> - correct patch title,
>
> v3:
> - fixed missing allwinner in front of compatible,
> - updated compatible to allwinner,sun8i-a33-ths to better reflect the
> datasheet's name,
> - updated example's DT node name and label to ths,
>
> added in v2
> .../devicetree/bindings/mfd/sun4i-gpadc.txt | 59 ++++++++++++++++++++++
> 1 file changed, 59 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
Applied, thanks.
> diff --git a/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> new file mode 100644
> index 0000000..badff36
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/sun4i-gpadc.txt
> @@ -0,0 +1,59 @@
> +Allwinner SoCs' GPADC Device Tree bindings
> +------------------------------------------
> +The Allwinner SoCs all have an ADC that can also act as a thermal sensor
> +and sometimes as a touchscreen controller.
> +
> +Required properties:
> + - compatible: "allwinner,sun8i-a33-ths",
> + - reg: mmio address range of the chip,
> + - #thermal-sensor-cells: shall be 0,
> + - #io-channel-cells: shall be 0,
> +
> +Example:
> + ths: ths@01c25000 {
> + compatible = "allwinner,sun8i-a33-ths";
> + reg = <0x01c25000 0x100>;
> + #thermal-sensor-cells = <0>;
> + #io-channel-cells = <0>;
> + };
> +
> +sun4i, sun5i and sun6i SoCs are also supported via the older binding:
> +
> +sun4i resistive touchscreen controller
> +--------------------------------------
> +
> +Required properties:
> + - compatible: "allwinner,sun4i-a10-ts", "allwinner,sun5i-a13-ts" or
> + "allwinner,sun6i-a31-ts"
> + - reg: mmio address range of the chip
> + - interrupts: interrupt to which the chip is connected
> + - #thermal-sensor-cells: shall be 0
> +
> +Optional properties:
> + - allwinner,ts-attached : boolean indicating that an actual touchscreen
> + is attached to the controller
> + - allwinner,tp-sensitive-adjust : integer (4 bits)
> + adjust sensitivity of pen down detection
> + between 0 (least sensitive) and 15
> + (defaults to 15)
> + - allwinner,filter-type : integer (2 bits)
> + select median and averaging filter
> + samples used for median / averaging filter
> + 0: 4/2
> + 1: 5/3
> + 2: 8/4
> + 3: 16/8
> + (defaults to 1)
> +
> +Example:
> +
> + rtp: rtp@01c25000 {
> + compatible = "allwinner,sun4i-a10-ts";
> + reg = <0x01c25000 0x100>;
> + interrupts = <29>;
> + allwinner,ts-attached;
> + #thermal-sensor-cells = <0>;
> + /* sensitive/noisy touch panel */
> + allwinner,tp-sensitive-adjust = <0>;
> + allwinner,filter-type = <3>;
> + };
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCH 02/11] arm64: allwinner: a64: add NMI controller on A64
From: Chen-Yu Tsai @ 2017-04-05 11:59 UTC (permalink / raw)
To: Maxime Ripard
Cc: Chen-Yu Tsai, Icenowy Zheng, Lee Jones, Rob Herring,
Liam Girdwood, devicetree, linux-sunxi, linux-kernel,
linux-arm-kernel
In-Reply-To: <20170405072832.qunhfngatebcgn4q@lukather>
On Wed, Apr 5, 2017 at 3:28 PM, Maxime Ripard
<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> On Wed, Apr 05, 2017 at 02:20:31PM +0800, Chen-Yu Tsai wrote:
>> On Wed, Apr 5, 2017 at 2:11 PM, Maxime Ripard
>> <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>> > On Wed, Apr 05, 2017 at 11:51:45AM +0800, Chen-Yu Tsai wrote:
>> >> On Wed, Apr 5, 2017 at 2:01 AM, Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org> wrote:
>> >> > Allwinner A64 SoC features a NMI controller, which is usually connected
>> >> > to the AXP PMIC.
>> >> >
>> >> > Add support for it.
>> >> >
>> >> > Signed-off-by: Icenowy Zheng <icenowy-h8G6r0blFSE@public.gmane.org>
>> >>
>> >> This might not be the best representation of the R_INTC block. Though
>> >> we'd need to change it for all SoCs if we want to be accurate. For now,
>> >
>> > What do you think would be a good representation?
>>
>> My gut feeling is that this is the old INTC from sun4/5i.
>
> Ah, that would make sense.
>
>> It's supposed to be the interrupt controller for the embedded low
>> power core. I've not done a thorough comparison though.
>
> Do we have some documentation / code for this one?
I can't remember where or if I saw any. If Allwinner ever released
any source code for the OpenRISC core we could actually verify it.
However the base address of this block, in addition to the register
offsets found in the driver for "allwinner,sun6i-a31-sc-nmi" do match
up with the sun4i irqchip. The question is if any of the other interrupt
lines are hooked up, and if yes, to what. A possibility would be that
it has all the interrupt lines in the SoC also hooked up, at the same
numbers as the GIC (minus 32). It would feed both the GIC and CPUS.
This is just an educated guess though.
Regards
ChenYu
^ permalink raw reply
* Re: [PATCH v6 17/39] platform: add video-multiplexer subdevice driver
From: Lucas Stach @ 2017-04-05 11:58 UTC (permalink / raw)
To: Pavel Machek
Cc: mark.rutland, andrew-ct.chen, minghsiu.tsai, nick, songjun.wu,
hverkuil, shuah, devel, markus.heiser, Steve Longerbeam,
robert.jarzmik, linux, geert, Steve Longerbeam, p.zabel,
linux-media, devicetree, sakari.ailus, arnd, Sascha Hauer,
tiffany.lin, bparrot, laurent.pinchart+renesas, horms+renesas,
mchehab, linux-arm-kernel, niklas.soderlund+renesas, gregkh,
linux-kernel, robh+dt, jean-christophe.trotin, kernel
In-Reply-To: <20170405111857.GA26831@amd>
Am Mittwoch, den 05.04.2017, 13:18 +0200 schrieb Pavel Machek:
> Hi!
>
> > + * video stream multiplexer controlled via gpio or syscon
> > + *
> > + * Copyright (C) 2013 Pengutronix, Sascha Hauer <kernel@pengutronix.de>
> > + * Copyright (C) 2016 Pengutronix, Philipp Zabel <kernel@pengutronix.de>
>
> This is actually quite interesting. Same email address for two
> people...
>
> Plus, I believe this wants to say that copyright is with Pengutronix,
> not Sascha and Philipp. In that case you probably want to list
> copyright and authors separately?
>
Nope, copyright doesn't get transferred to the employer within the rules
of the German "Urheberrecht", but stays at the original author of the
code.
Same email is just to ensure that any requests regarding this code get
routed to the right people, even if someone leaves the company or is
temporarily unavailable. kernel@ is a list for the Pengutronix kernel
team.
Regards,
Lucas
^ permalink raw reply
* [PATCH v2 3/3] clk: vc5: Add support for IDT VersaClock 5P49V5935
From: Alexey Firago @ 2017-04-05 11:46 UTC (permalink / raw)
To: mturquette-rdvid1DuHRBWk0Htik3J/w, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
marek.vasut-Re5JQEeQqe8AvxtiuMwx3w, geert-Td1EMuHUCqxL1ZNQvxDV9g,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Alexey Firago
In-Reply-To: <1491392819-698-1-git-send-email-alexey_firago-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
Update IDT VersaClock 5 driver to support 5P49V5935. This chip has
two clock inputs (internal XTAL or external CLKIN), four fractional
dividers (FODs) and five clock outputs (four universal clock outputs
and one reference clock output at OUT0_SELB_I2C).
Current driver supports up to 2 FODs and up to 3 clock outputs. This
patch sets max number of supported FODs to 4 and max number of supported
clock outputs to 5.
Signed-off-by: Alexey Firago <alexey_firago-nmGgyN9QBj3QT0dZR+AlfA@public.gmane.org>
---
drivers/clk/clk-versaclock5.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/clk-versaclock5.c b/drivers/clk/clk-versaclock5.c
index 7d31390..4c268e3 100644
--- a/drivers/clk/clk-versaclock5.c
+++ b/drivers/clk/clk-versaclock5.c
@@ -114,10 +114,10 @@
#define VC5_MUX_IN_CLKIN BIT(1)
/* Maximum number of clk_out supported by this driver */
-#define VC5_MAX_CLK_OUT_NUM 3
+#define VC5_MAX_CLK_OUT_NUM 5
/* Maximum number of FODs supported by this driver */
-#define VC5_MAX_FOD_NUM 2
+#define VC5_MAX_FOD_NUM 4
/* flags to describe chip features */
/* chip has built-in oscilator */
@@ -127,6 +127,7 @@
enum vc5_model {
IDT_VC5_5P49V5923,
IDT_VC5_5P49V5933,
+ IDT_VC5_5P49V5935,
};
/* Structure to describe features of a particular VC5 model */
@@ -594,6 +595,7 @@ static int vc5_map_index_to_output(const enum vc5_model model,
case IDT_VC5_5P49V5933:
return (n == 0) ? 0 : 3;
case IDT_VC5_5P49V5923:
+ case IDT_VC5_5P49V5935:
default:
return n;
}
@@ -798,9 +800,17 @@ static const struct vc5_chip_info idt_5p49v5933_info = {
.flags = VC5_HAS_INTERNAL_XTAL,
};
+static const struct vc5_chip_info idt_5p49v5935_info = {
+ .model = IDT_VC5_5P49V5935,
+ .clk_fod_cnt = 4,
+ .clk_out_cnt = 5,
+ .flags = VC5_HAS_INTERNAL_XTAL,
+};
+
static const struct i2c_device_id vc5_id[] = {
{ "5p49v5923", .driver_data = IDT_VC5_5P49V5923 },
{ "5p49v5933", .driver_data = IDT_VC5_5P49V5933 },
+ { "5p49v5935", .driver_data = IDT_VC5_5P49V5935 },
{ }
};
MODULE_DEVICE_TABLE(i2c, vc5_id);
@@ -808,6 +818,7 @@ MODULE_DEVICE_TABLE(i2c, vc5_id);
static const struct of_device_id clk_vc5_of_match[] = {
{ .compatible = "idt,5p49v5923", .data = &idt_5p49v5923_info },
{ .compatible = "idt,5p49v5933", .data = &idt_5p49v5933_info },
+ { .compatible = "idt,5p49v5935", .data = &idt_5p49v5935_info },
{ },
};
MODULE_DEVICE_TABLE(of, clk_vc5_of_match);
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v2 2/3] clk: vc5: Add bindings for IDT VersaClock 5P49V5935
From: Alexey Firago @ 2017-04-05 11:46 UTC (permalink / raw)
To: mturquette, sboyd, robh+dt, marek.vasut, geert, linux-clk,
devicetree
Cc: Alexey Firago
In-Reply-To: <1491392819-698-1-git-send-email-alexey_firago@mentor.com>
IDT VersaClock 5 5P49V5935 has 4 clock outputs, 4 fractional dividers.
Input clock source can be taken from either integrated crystal or from
external reference clock.
Signed-off-by: Alexey Firago <alexey_firago@mentor.com>
---
.../devicetree/bindings/clock/idt,versaclock5.txt | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.txt b/Documentation/devicetree/bindings/clock/idt,versaclock5.txt
index 87e9c47..53d7e50 100644
--- a/Documentation/devicetree/bindings/clock/idt,versaclock5.txt
+++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.txt
@@ -6,18 +6,21 @@ from 3 to 12 output clocks.
==I2C device node==
Required properties:
-- compatible: shall be one of "idt,5p49v5923" , "idt,5p49v5933".
+- compatible: shall be one of "idt,5p49v5923" , "idt,5p49v5933" ,
+ "idt,5p49v5935".
- reg: i2c device address, shall be 0x68 or 0x6a.
- #clock-cells: from common clock binding; shall be set to 1.
- clocks: from common clock binding; list of parent clock handles,
- 5p49v5923: (required) either or both of XTAL or CLKIN
reference clock.
- - 5p49v5933: (optional) property not present (internal
+ - 5p49v5933 and
+ - 5p49v5935: (optional) property not present (internal
Xtal used) or CLKIN reference
clock.
- clock-names: from common clock binding; clock input names, can be
- 5p49v5923: (required) either or both of "xin", "clkin".
- - 5p49v5933: (optional) property not present or "clkin".
+ - 5p49v5933 and
+ - 5p49v5935: (optional) property not present or "clkin".
==Mapping between clock specifier and physical pins==
@@ -34,6 +37,13 @@ clock specifier, the following mapping applies:
1 -- OUT1
2 -- OUT4
+5P49V5935:
+ 0 -- OUT0_SEL_I2CB
+ 1 -- OUT1
+ 2 -- OUT2
+ 3 -- OUT3
+ 4 -- OUT4
+
==Example==
/* 25MHz reference crystal */
--
2.7.4
^ permalink raw reply related
* [PATCH v2 1/3] clk: vc5: Add structure to describe particular chip features
From: Alexey Firago @ 2017-04-05 11:46 UTC (permalink / raw)
To: mturquette, sboyd, robh+dt, marek.vasut, geert, linux-clk,
devicetree
Cc: Alexey Firago
In-Reply-To: <1491392819-698-1-git-send-email-alexey_firago@mentor.com>
Introduce vc5_chip_info structure to describe features of a particular
VC5 chip (id, number of FODs, number of outputs, flags).
For now flags are only used to indicate if chip has internal XTAL.
vc5_chip_info is set on probe from the matched of_device_id->data.
Also add defines to specify maximum number of FODs and clock outputs
supported by the driver.
With these changes it should be easier to extend driver to support
more VC5 models.
Signed-off-by: Alexey Firago <alexey_firago@mentor.com>
---
drivers/clk/clk-versaclock5.c | 69 +++++++++++++++++++++++++++++++++----------
1 file changed, 53 insertions(+), 16 deletions(-)
diff --git a/drivers/clk/clk-versaclock5.c b/drivers/clk/clk-versaclock5.c
index 56741f3..7d31390 100644
--- a/drivers/clk/clk-versaclock5.c
+++ b/drivers/clk/clk-versaclock5.c
@@ -113,12 +113,30 @@
#define VC5_MUX_IN_XIN BIT(0)
#define VC5_MUX_IN_CLKIN BIT(1)
+/* Maximum number of clk_out supported by this driver */
+#define VC5_MAX_CLK_OUT_NUM 3
+
+/* Maximum number of FODs supported by this driver */
+#define VC5_MAX_FOD_NUM 2
+
+/* flags to describe chip features */
+/* chip has built-in oscilator */
+#define VC5_HAS_INTERNAL_XTAL BIT(0)
+
/* Supported IDT VC5 models. */
enum vc5_model {
IDT_VC5_5P49V5923,
IDT_VC5_5P49V5933,
};
+/* Structure to describe features of a particular VC5 model */
+struct vc5_chip_info {
+ const enum vc5_model model;
+ const int clk_fod_cnt;
+ const int clk_out_cnt;
+ u32 flags;
+};
+
struct vc5_driver_data;
struct vc5_hw_data {
@@ -132,15 +150,15 @@ struct vc5_hw_data {
struct vc5_driver_data {
struct i2c_client *client;
struct regmap *regmap;
- enum vc5_model model;
+ struct vc5_chip_info *chip_info;
struct clk *pin_xin;
struct clk *pin_clkin;
unsigned char clk_mux_ins;
struct clk_hw clk_mux;
struct vc5_hw_data clk_pll;
- struct vc5_hw_data clk_fod[2];
- struct vc5_hw_data clk_out[3];
+ struct vc5_hw_data clk_fod[VC5_MAX_FOD_NUM];
+ struct vc5_hw_data clk_out[VC5_MAX_CLK_OUT_NUM];
};
static const char * const vc5_mux_names[] = {
@@ -563,7 +581,7 @@ static struct clk_hw *vc5_of_clk_get(struct of_phandle_args *clkspec,
struct vc5_driver_data *vc5 = data;
unsigned int idx = clkspec->args[0];
- if (idx > 2)
+ if (idx >= vc5->chip_info->clk_out_cnt)
return ERR_PTR(-EINVAL);
return &vc5->clk_out[idx].hw;
@@ -591,7 +609,7 @@ static int vc5_probe(struct i2c_client *client,
struct vc5_driver_data *vc5;
struct clk_init_data init;
const char *parent_names[2];
- unsigned int n, idx;
+ unsigned int n, idx = 0;
int ret;
vc5 = devm_kzalloc(&client->dev, sizeof(*vc5), GFP_KERNEL);
@@ -600,7 +618,12 @@ static int vc5_probe(struct i2c_client *client,
i2c_set_clientdata(client, vc5);
vc5->client = client;
- vc5->model = (enum vc5_model)of_id->data;
+
+ vc5->chip_info = (struct vc5_chip_info *)of_id->data;
+ if (!vc5->chip_info) {
+ dev_err(&client->dev, "No device match found\n");
+ return -ENODEV;
+ }
vc5->pin_xin = devm_clk_get(&client->dev, "xin");
if (PTR_ERR(vc5->pin_xin) == -EPROBE_DEFER)
@@ -622,8 +645,8 @@ static int vc5_probe(struct i2c_client *client,
if (!IS_ERR(vc5->pin_xin)) {
vc5->clk_mux_ins |= VC5_MUX_IN_XIN;
parent_names[init.num_parents++] = __clk_get_name(vc5->pin_xin);
- } else if (vc5->model == IDT_VC5_5P49V5933) {
- /* IDT VC5 5P49V5933 has built-in oscilator. */
+ } else if (vc5->chip_info->flags & VC5_HAS_INTERNAL_XTAL) {
+ /* chip has built-in oscilator. */
vc5->pin_xin = clk_register_fixed_rate(&client->dev,
"internal-xtal", NULL,
0, 25000000);
@@ -672,8 +695,8 @@ static int vc5_probe(struct i2c_client *client,
}
/* Register FODs */
- for (n = 0; n < 2; n++) {
- idx = vc5_map_index_to_output(vc5->model, n);
+ for (n = 0; n < vc5->chip_info->clk_fod_cnt; n++) {
+ idx = vc5_map_index_to_output(vc5->chip_info->model, n);
memset(&init, 0, sizeof(init));
init.name = vc5_fod_names[idx];
init.ops = &vc5_fod_ops;
@@ -709,8 +732,8 @@ static int vc5_probe(struct i2c_client *client,
}
/* Register FOD-connected OUTx outputs */
- for (n = 1; n < 3; n++) {
- idx = vc5_map_index_to_output(vc5->model, n - 1);
+ for (n = 1; n < vc5->chip_info->clk_out_cnt; n++) {
+ idx = vc5_map_index_to_output(vc5->chip_info->model, n - 1);
parent_names[0] = vc5_fod_names[idx];
if (n == 1)
parent_names[1] = vc5_mux_names[0];
@@ -744,7 +767,7 @@ static int vc5_probe(struct i2c_client *client,
return 0;
err_clk:
- if (vc5->model == IDT_VC5_5P49V5933)
+ if (vc5->chip_info->flags & VC5_HAS_INTERNAL_XTAL)
clk_unregister_fixed_rate(vc5->pin_xin);
return ret;
}
@@ -755,12 +778,26 @@ static int vc5_remove(struct i2c_client *client)
of_clk_del_provider(client->dev.of_node);
- if (vc5->model == IDT_VC5_5P49V5933)
+ if (vc5->chip_info->flags & VC5_HAS_INTERNAL_XTAL)
clk_unregister_fixed_rate(vc5->pin_xin);
return 0;
}
+static const struct vc5_chip_info idt_5p49v5923_info = {
+ .model = IDT_VC5_5P49V5923,
+ .clk_fod_cnt = 2,
+ .clk_out_cnt = 3,
+ .flags = 0,
+};
+
+static const struct vc5_chip_info idt_5p49v5933_info = {
+ .model = IDT_VC5_5P49V5933,
+ .clk_fod_cnt = 2,
+ .clk_out_cnt = 3,
+ .flags = VC5_HAS_INTERNAL_XTAL,
+};
+
static const struct i2c_device_id vc5_id[] = {
{ "5p49v5923", .driver_data = IDT_VC5_5P49V5923 },
{ "5p49v5933", .driver_data = IDT_VC5_5P49V5933 },
@@ -769,8 +806,8 @@ static const struct i2c_device_id vc5_id[] = {
MODULE_DEVICE_TABLE(i2c, vc5_id);
static const struct of_device_id clk_vc5_of_match[] = {
- { .compatible = "idt,5p49v5923", .data = (void *)IDT_VC5_5P49V5923 },
- { .compatible = "idt,5p49v5933", .data = (void *)IDT_VC5_5P49V5933 },
+ { .compatible = "idt,5p49v5923", .data = &idt_5p49v5923_info },
+ { .compatible = "idt,5p49v5933", .data = &idt_5p49v5933_info },
{ },
};
MODULE_DEVICE_TABLE(of, clk_vc5_of_match);
--
2.7.4
^ permalink raw reply related
* [PATCH v2 0/3] clk: Add support for IDT 5P49V5935
From: Alexey Firago @ 2017-04-05 11:46 UTC (permalink / raw)
To: mturquette-rdvid1DuHRBWk0Htik3J/w, sboyd-sgV2jX0FEOL9JmXXK+q4OQ,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
marek.vasut-Re5JQEeQqe8AvxtiuMwx3w, geert-Td1EMuHUCqxL1ZNQvxDV9g,
linux-clk-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: Alexey Firago
This series adds support for IDT VersaClock 5P49V5935 programmable clock
generator to the existing clk-versaclock5 driver.
Patches were verified on Avnet UltraZed-EG board with IO Carrier Card.
Changes in V2:
- Introduce vc5_chip_info structure describing chip features
- Set vc5_chip_info for the supported chips using clk_vc5_of_match[].data
- Add 5P49V5935 support using vc5_chip_info approach
- Fix idx comparison in vc5_of_clk_get ('>' to '>=')
Alexey Firago (3):
clk: vc5: Add structure to describe particular chip features
clk: vc5: Add bindings for IDT VersaClock 5P49V5935
clk: vc5: Add support for IDT VersaClock 5P49V5935
.../devicetree/bindings/clock/idt,versaclock5.txt | 16 ++++-
drivers/clk/clk-versaclock5.c | 80 +++++++++++++++++-----
2 files changed, 77 insertions(+), 19 deletions(-)
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v6 19/39] media: Add i.MX media core driver
From: Pavel Machek @ 2017-04-05 11:34 UTC (permalink / raw)
To: Steve Longerbeam
Cc: mark.rutland, andrew-ct.chen, minghsiu.tsai, sakari.ailus, nick,
songjun.wu, hverkuil, Steve Longerbeam, robert.jarzmik, devel,
markus.heiser, laurent.pinchart+renesas, shuah, linux, geert,
linux-media, devicetree, kernel, arnd, mchehab, bparrot, robh+dt,
horms+renesas, tiffany.lin, linux-arm-kernel,
niklas.soderlund+renesas, gregkh, linux-kernel,
jean-christophe.trotin, p.zabel, fabio.estevam, shawnguo,
sudipm.mukherjee
In-Reply-To: <1490661656-10318-20-git-send-email-steve_longerbeam@mentor.com>
[-- Attachment #1.1: Type: text/plain, Size: 435 bytes --]
Hi!
> +References
> +----------
> +
> +[1] "i.MX 6Dual/6Quad Applications Processor Reference Manual"
> +[2] "i.MX 6Solo/6DualLite Applications Processor Reference Manual"
[2] is not present in the text above. [1] is there many times. What is
purpose of this section?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 169 bytes --]
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
^ permalink raw reply
* Re: [PATCH v6 19/39] media: Add i.MX media core driver
From: Pavel Machek @ 2017-04-05 11:32 UTC (permalink / raw)
To: Steve Longerbeam
Cc: mark.rutland, andrew-ct.chen, minghsiu.tsai, sakari.ailus, nick,
songjun.wu, hverkuil, Steve Longerbeam, robert.jarzmik, devel,
markus.heiser, laurent.pinchart+renesas, shuah, linux, geert,
linux-media, devicetree, kernel, arnd, mchehab, bparrot, robh+dt,
horms+renesas, tiffany.lin, linux-arm-kernel,
niklas.soderlund+renesas, gregkh, linux-kernel,
jean-christophe.trotin, p.zabel, fabio.estevam, shawnguo,
sudipm.mukherjee
In-Reply-To: <1490661656-10318-20-git-send-email-steve_longerbeam@mentor.com>
[-- Attachment #1.1: Type: text/plain, Size: 1779 bytes --]
Hi!
> +https://boundarydevices.com/products/nit6x_5mp
I'd use /product/ in url, as it redirects there.
> +https://boundarydevices.com/product/nit6x_5mp_mipi
..and for consistency.
> +The following example configures a direct conversion pipeline to capture
> +from the OV5640, transmitting on MIPI CSI-2 virtual channel 1. $sensorfmt
> +can be any format supported by the OV5640. $sensordim is the frame
> +dimension part of $sensorfmt (minus the mbus pixel code). $outputfmt can
> +be any format supported by the ipu1_ic_prpenc entity at its output pad:
> +
> +.. code-block:: none
> +
> + # Setup links
> + media-ctl -l "'ov5640 1-003c':0 -> 'imx6-mipi-csi2':0[1]"
> + media-ctl -l "'imx6-mipi-csi2':2 -> 'ipu1_csi1':0[1]"
> + media-ctl -l "'ipu1_csi1':1 -> 'ipu1_ic_prp':0[1]"
> + media-ctl -l "'ipu1_ic_prp':1 -> 'ipu1_ic_prpenc':0[1]"
> + media-ctl -l "'ipu1_ic_prpenc':1 -> 'ipu1_ic_prpenc capture':0[1]"
> + # Configure pads
> + media-ctl -V "'ov5640 1-003c':0 [fmt:$sensorfmt field:none]"
> + media-ctl -V "'imx6-mipi-csi2':2 [fmt:$sensorfmt field:none]"
> + media-ctl -V "'ipu1_csi1':1 [fmt:AYUV32/$sensordim field:none]"
> + media-ctl -V "'ipu1_ic_prp':1 [fmt:AYUV32/$sensordim field:none]"
> + media-ctl -V "'ipu1_ic_prpenc':1 [fmt:$outputfmt field:none]"
> +
> +Streaming can then begin on "ipu1_ic_prpenc capture" node. The v4l2-ctl
> +tool can be used to select any supported YUV or RGB pixelformat on the
> +capture device node.
Nothing for you to fix here, but we should really create some
library-like interface for media-ctl.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 169 bytes --]
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
^ permalink raw reply
* Re: [PATCH v3 0/3] add support of usb2-phy for rk3328
From: Kishon Vijay Abraham I @ 2017-04-05 11:24 UTC (permalink / raw)
To: Meng Dongyang, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, geert+renesas-gXvu3+zWzMSzQB+pC5nmwQ,
yoshihiro.shimoda.uh-zM6kxYcvzFBBDgjK7y7TUQ,
martin.blumenstingl-gM/Ye1E23mwN+BqQ9rBEUg,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA, heiko-4mtYJXux2i+zQB+pC5nmwQ
Cc: huangtao-TNX95d0MmH7DzftRWevZcw,
frank.wang-TNX95d0MmH7DzftRWevZcw,
linux-usb-u79uwXL29TY76Z2rM5mHXA,
kever.yang-TNX95d0MmH7DzftRWevZcw,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
william.wu-TNX95d0MmH7DzftRWevZcw
In-Reply-To: <1488763778-27499-1-git-send-email-daniel.meng-TNX95d0MmH7DzftRWevZcw@public.gmane.org>
On Monday 06 March 2017 06:59 AM, Meng Dongyang wrote:
> The config information of RK3328 about address and port property
> is different from other platform. So adds config information in the
> data of match table and the device tree bindings description for
> usb2-phy.
>
> Changes in v2:
> - move usb2-phy grf specification to .../devicetree/bindings/soc/rockchip/grf.txt
> - add otg port config information of rk3328
> Changes in v3:
> - remove tuning function and id pin configs
> - delete example of usb2-phy grf in grf.txt
removed the version history in commit log and merged the series.
Thanks
Kishon
>
> Meng Dongyang (3):
> dt-bindings: phy: add assign clock property in usb2-phy node
> dt-bindings: phy: add DT bindings for usb2-phy grf
> phy: rockchip-inno-usb2: add support of usb2-phy for rk3328
>
> .../bindings/phy/phy-rockchip-inno-usb2.txt | 6 +++
> .../devicetree/bindings/soc/rockchip/grf.txt | 4 ++
> drivers/phy/phy-rockchip-inno-usb2.c | 44 ++++++++++++++++++++++
> 3 files changed, 54 insertions(+)
>
^ permalink raw reply
* Re: [PATCH v3 00/11] add thermal throttling to Allwinner A33 SoC
From: Quentin Schulz @ 2017-04-05 11:23 UTC (permalink / raw)
To: Lee Jones
Cc: mark.rutland-5wv7dgnIgG8,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
lars-Qo5EllUWu/uELgA04lAiVw, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w,
linux-I+IVW8TIWO2tmTQ+vhA3Yw, linux-kernel-u79uwXL29TY76Z2rM5mHXA,
wens-jdAy2FN1RRM, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
pmeerw-jW+XmwGofnusTnJN9+BGXg, knaack.h-Mmb7MZpHnFY,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-input-u79uwXL29TY76Z2rM5mHXA, jic23-DgEjT+Ai2ygdnm+yROfE0A,
icenowy-ymACFijhrKM
In-Reply-To: <20170405095752.pji6o7u5no6svd5i@dell>
Hi Lee,
On 05/04/2017 11:57, Lee Jones wrote:
> On Wed, 05 Apr 2017, Quentin Schulz wrote:
>> On 04/04/2017 10:31, Lee Jones wrote:
>>> On Tue, 21 Mar 2017, Quentin Schulz wrote:
>>>> v3:
>>>> - fixed compatible name in DT and in documentation,
>>>> - fixed DT node name and label,
>>>> - added explanations in commit logs,
>>>> - moved frequencies that need overvolting to board DTS instead of A33 DTSI,
>>>> - fixed a typo in if is_enabled condition,
>>>> - removed all patches concerning Olimex Olinuxino (no HW to test on),
>>>
>>> What is the plan for this series?
>>>
>>> I'm guessing there are no hard dependencies on the ARM parts?
>>>
>>> If not, I'm happy to take the changes to 'drivers/*'.
>>>
>>
>> I've sent a v4 to add some Acked-by and change a few commit "titles".
>> It's ready to be merged with only the following patch required (which
>> Jonathan asked if you could merge it through the mfd tree): "[RESEND
>> PATCH v4] iio: adc: add support for X-Powers AXP20X and AXP22X PMICs
>> ADCs" (https://patchwork.kernel.org/patch/9660879/)
I got things mixed up between the two different IIO/ADC drivers I'm
trying to get merge. Forget about this dependency, that's not for this
patch series. Sorry for that.
>
> Right, but how would you like *this* patch-set applied?
>
> I'm guessing the ARM patches need to go in via ARM-SoC.
>
> What about the drivers/{input,iio,mfd} patches?
>
> I'm guessing they're to all go in via my tree?
>
Patches 1-2 - MFD maintainer I guess? (Lee)
Patches 3-4 - IIO maintainer (Jonathan)
Patches 5-8 - SUNXI maintainer (Maxime)
I think that should do it.
Quentin
>>>> [1] https://lkml.org/lkml/2016/12/13/298 : "[PATCH v9] add support for Allwinner
>>>> SoCs ADC"
>>>>
>>>> Thanks,
>>>> Quentin
>>>>
>>>> Maxime Ripard (1):
>>>> ARM: sun8i: a33: Add devfreq-based GPU cooling
>>>>
>>>> Quentin Schulz (10):
>>>> ARM: sun8i: a33: add operating-points-v2 property to all nodes
>>>> ARM: sun8i: a33: add all operating points
>>>> ARM: dts: sun8i: sina33: add cpu-supply
>>>> Documentation: DT: bindings: mfd: add A33 GPADC binding
>>>> Documentation: DT: bindings: input: touschcreen: remove sun4i
>>>> documentation
>>>> iio: adc: sun4i-gpadc-iio: move code used in MFD probing to new
>>>> function
>>>> iio: adc: sun4i-gpadc-iio: add support for A33 thermal sensor
>>>> ARM: dtsi: sun8i: a33: add thermal sensor
>>>> ARM: dtsi: sun8i: a33: add CPU thermal throttling
>>>> ARM: sun8i: sina33: add highest OPP of CPUs
>>>>
>>>> .../touchscreen/sun4i.txt => mfd/sun4i-gpadc.txt} | 21 +++
>>>> arch/arm/boot/dts/sun8i-a23-a33.dtsi | 1 +
>>>> arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 18 +++
>>>> arch/arm/boot/dts/sun8i-a33.dtsi | 141 +++++++++++++++++
>>>> drivers/iio/adc/Kconfig | 2 +-
>>>> drivers/iio/adc/sun4i-gpadc-iio.c | 170 +++++++++++++++++----
>>>> include/linux/mfd/sun4i-gpadc.h | 4 +
>>>> 7 files changed, 324 insertions(+), 33 deletions(-)
>>>> rename Documentation/devicetree/bindings/{input/touchscreen/sun4i.txt => mfd/sun4i-gpadc.txt} (64%)
>>>>
>>>
>>
>
--
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v6 17/39] platform: add video-multiplexer subdevice driver
From: Pavel Machek @ 2017-04-05 11:18 UTC (permalink / raw)
To: Steve Longerbeam
Cc: mark.rutland, andrew-ct.chen, minghsiu.tsai, sakari.ailus, nick,
songjun.wu, hverkuil, Steve Longerbeam, robert.jarzmik, devel,
markus.heiser, laurent.pinchart+renesas, shuah, linux, geert,
Sascha Hauer, linux-media, devicetree, kernel, arnd, mchehab,
bparrot, robh+dt, horms+renesas, tiffany.lin, linux-arm-kernel,
niklas.soderlund+renesas, gregkh, linux-kernel,
jean-christophe.trotin, p.zabel, fabio.estevam, shawnguo
In-Reply-To: <1490661656-10318-18-git-send-email-steve_longerbeam@mentor.com>
[-- Attachment #1.1: Type: text/plain, Size: 619 bytes --]
Hi!
> + * video stream multiplexer controlled via gpio or syscon
> + *
> + * Copyright (C) 2013 Pengutronix, Sascha Hauer <kernel@pengutronix.de>
> + * Copyright (C) 2016 Pengutronix, Philipp Zabel <kernel@pengutronix.de>
This is actually quite interesting. Same email address for two
people...
Plus, I believe this wants to say that copyright is with Pengutronix,
not Sascha and Philipp. In that case you probably want to list
copyright and authors separately?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
[-- Attachment #2: Type: text/plain, Size: 169 bytes --]
_______________________________________________
devel mailing list
devel@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
^ permalink raw reply
* Re: [PATCH] media: mtk-vcodec: remove informative log
From: Tiffany Lin @ 2017-04-05 11:09 UTC (permalink / raw)
To: Minghsiu Tsai
Cc: Hans Verkuil, daniel.thompson, Rob Herring, Mauro Carvalho Chehab,
Matthias Brugger, Daniel Kurtz, Pawel Osciak, srv_heupstream,
Eddie Huang, Yingjoe Chen, Wu-Cheng Li, devicetree, linux-kernel,
linux-arm-kernel, linux-media, linux-mediatek
In-Reply-To: <1491389669-32737-1-git-send-email-minghsiu.tsai@mediatek.com>
On Wed, 2017-04-05 at 18:54 +0800, Minghsiu Tsai wrote:
> Driver is stable. Remove DEBUG definition from driver.
>
> There are debug message in /var/log/messages if DEBUG is defined,
> such as:
> [MTK_V4L2] level=0 fops_vcodec_open(),170: decoder capability 0
> [MTK_V4L2] level=0 fops_vcodec_open(),177: 16000000.vcodec decoder [0]
> [MTK_V4L2] level=0 fops_vcodec_release(),200: [0] decoder
>
> Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
Acked-by:Tiffany Lin <Tiffany.lin@mediatek.com>
> ---
> drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> index 7d55975..1248083 100644
> --- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> +++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
> @@ -31,7 +31,6 @@ struct mtk_vcodec_mem {
> extern int mtk_v4l2_dbg_level;
> extern bool mtk_vcodec_dbg;
>
> -#define DEBUG 1
>
> #if defined(DEBUG)
>
^ permalink raw reply
* Re: [PATCH v4 2/3] Broadcom USB DRD Phy driver for Northstar2
From: Kishon Vijay Abraham I @ 2017-04-05 11:00 UTC (permalink / raw)
To: Raviteja Garimella, Rob Herring, Mark Rutland, Ray Jui,
Scott Branden, Jon Mason, Catalin Marinas, Will Deacon
Cc: devicetree, bcm-kernel-feedback-list, linux-kernel,
linux-arm-kernel
In-Reply-To: <1490704052-11314-3-git-send-email-raviteja.garimella@broadcom.com>
Hi,
On Tuesday 28 March 2017 05:57 PM, Raviteja Garimella wrote:
> This is driver for USB DRD Phy used in Broadcom's Northstar2
> SoC. The phy can be configured to be in Device mode or Host
> mode based on the type of cable connected to the port. The
> driver registers to extcon framework to get appropriate
> connect events for Host/Device cables connect/disconnect
> states based on VBUS and ID interrupts.
$patch should be phy: phy-bcm-ns2-usbdrd: USB DRD Phy driver for Broadcoms
Northstar2.
Sorry for not letting you know this earlier. But I feel the design of the
driver should be changed. Extcon shouldn't be used here. The extcon
notifications should be sent to the consumer driver and the consumer driver
should be responsible for invoking the phy ops.
The phy ops being invoked during extcon events doesn't look right.
Thanks
Kishon
^ permalink raw reply
* [PATCH] media: mtk-vcodec: remove informative log
From: Minghsiu Tsai @ 2017-04-05 10:54 UTC (permalink / raw)
To: Hans Verkuil, daniel.thompson, Rob Herring, Mauro Carvalho Chehab,
Matthias Brugger, Daniel Kurtz, Pawel Osciak, Tiffany Lin
Cc: srv_heupstream, Eddie Huang, Yingjoe Chen, Wu-Cheng Li,
devicetree, linux-kernel, linux-arm-kernel, linux-media,
linux-mediatek, Minghsiu Tsai
Driver is stable. Remove DEBUG definition from driver.
There are debug message in /var/log/messages if DEBUG is defined,
such as:
[MTK_V4L2] level=0 fops_vcodec_open(),170: decoder capability 0
[MTK_V4L2] level=0 fops_vcodec_open(),177: 16000000.vcodec decoder [0]
[MTK_V4L2] level=0 fops_vcodec_release(),200: [0] decoder
Signed-off-by: Minghsiu Tsai <minghsiu.tsai@mediatek.com>
---
drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
index 7d55975..1248083 100644
--- a/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
+++ b/drivers/media/platform/mtk-vcodec/mtk_vcodec_util.h
@@ -31,7 +31,6 @@ struct mtk_vcodec_mem {
extern int mtk_v4l2_dbg_level;
extern bool mtk_vcodec_dbg;
-#define DEBUG 1
#if defined(DEBUG)
--
1.9.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox