* [PATCH v3 0/2] eeprom: Add IDT 89HPESx EEPROM/CSR driver
From: Serge Semin @ 2016-11-29 22:27 UTC (permalink / raw)
To: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A, andrew-g2DYL2Zd6BY,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8
Cc: Sergey.Semin-vHJ8rsvMqnUPfZBKTuL5GA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Serge Semin
In-Reply-To: <1480372701-30560-1-git-send-email-fancer.lancer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Changelog v3:
- Get rid of dev_*_idt() macros
- Replace to_pdev_kobj() macro with naked dev_get_drvdata() call
- Return naked 0 instead of SUCCESS macro
- IDT CSR debug file is moved to debugfs
- BIN_ATTR_RW is used to declare sysfs binary attribute
- Moved bindings file to a separate patch
- Need to create a specific bin_attribute structure for each device
- Perform a few read retries with delays if EEPROM is busy
Signed-off-by: Serge Semin <fancer.lancer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Serge Semin (2):
eeprom: Add IDT 89HPESx EEPROM/CSR driver
eeprom: Add IDT 89HPESx driver dts-binding file
.../devicetree/bindings/misc/idt_89hpesx.txt | 41 +
drivers/misc/eeprom/Kconfig | 10 +
drivers/misc/eeprom/Makefile | 1 +
drivers/misc/eeprom/idt_89hpesx.c | 1574 ++++++++++++++++++++
4 files changed, 1626 insertions(+)
create mode 100644 Documentation/devicetree/bindings/misc/idt_89hpesx.txt
create mode 100644 drivers/misc/eeprom/idt_89hpesx.c
--
2.6.6
--
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 3/5] ARM: dts: sun8i-h3: add HDMI video nodes
From: Jernej Skrabec @ 2016-11-29 22:15 UTC (permalink / raw)
To: linux-sunxi
Cc: icenowy-ymACFijhrKM, airlied-cv59FeDIM0c,
maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW
In-Reply-To: <20161125112213.83420594eb435b6bb1a4d164-GANU6spQydw@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 3090 bytes --]
Hi Jean-François,
Dne petek, 25. november 2016 11.22.20 UTC+1 je oseba Jean-François Moine
napisala:
>
> On Fri, 25 Nov 2016 17:41:51 +0800
> Icenowy Zheng <ice...-ymACFijhrKM@public.gmane.org <javascript:>> wrote:
>
> > After removing CLK_PLL_DE's assigned-clock, the kernel passes
> compilation.
>
> The 'pll-de' and 'de' must have a fixed rate. Otherwise, if you do not
> use the legacy u-boot, I don't know which can be the rate of the DE.
>
> > However, it cannot recognize any HDMI screen...
> >
> > (My board is Orange Pi One, and I manually added status="okay"; to
> &lcd0, &de, &hdmi)
> >
> > [ 16.507802] sun8i-de2 1000000.de-controller: bound
> 1c0c000.lcd-controller (ops de2_lcd_ops [sun8i_de2_drm])
> > [ 16.675948] sun8i-de2 1000000.de-controller: bound 1ee0000.hdmi (ops
> de2_hdmi_fini [sun8i_de2_hdmi])
> > [ 16.685120] [drm] Supports vblank timestamp caching Rev 2
> (21.10.2013).
> > [ 16.695876] [drm] No driver support for vblank timestamp query.
> > [ 16.701862] sun8i-de2 1000000.de-controller: No connectors reported
> connected with modes
> > [ 16.713061] [drm] Cannot find any crtc or sizes - going 1024x768
> > [ 16.734214] Console: switching to colour frame buffer device 128x48
> > [ 16.751022] sun8i-de2 1000000.de-controller: fb0: frame buffer
> device
>
> I put a 'pr_warn' message is case the EDID cannot be read.
> Have you this message?
>
> Anyway, there is a problem with the EDID:
> - my Orange Pi 2 (H3) randomly fails to read it. But this succeeds after
> rebooting once or twice.
>
My U-Boot driver never exhibited a problem with reading EDID on OPi2.
However,
I'm reusing code from Rockchip HDMI U-Boot driver for this (with some
Allwinner
adjustments).
> - my Banana Pi M2+ (H3) reads it correctly each time.
> - my Banana Pi M3 (A83T) can never read it.
>
> BTW, on first tries, I was forcing a CEA mode thru the kernel command
> line. This was working with the OPi2 and BPiM3, but there was no sound.
> In the last version, I use a EDID in edid_firmware for having sound
> with the BPiM3. This works fine.
> But, forcing a CEA mode is no more possible, so, when the OPi2 cannot
> read the EDID, the system switches to a VGA mode (default 1024x768)
> which is not supported. It seems that this is your case.
>
> So, in brief, if your board cannot read the EDID, put a EDID somewhere
> and its path in /sys/module/drm_kms_helper/parameters/edid_firmware.
> There will be no console, but X11 will work correctly.
>
> --
> Ken ar c'hentañ | ** Breizh ha Linux atav! **
> Jef | http://moinejf.free.fr/
Best regards,
Jernej Škrabec
--
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.
[-- Attachment #1.2: Type: text/html, Size: 4388 bytes --]
^ permalink raw reply
* Re: [PATCH RESEND 2/2] gpio: axp209: add pinctrl support
From: Quentin Schulz @ 2016-11-29 22:13 UTC (permalink / raw)
To: Linus Walleij
Cc: Alexandre Courbot, Rob Herring, Mark Rutland, Chen-Yu Tsai,
Maxime Ripard, linux-gpio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <CACRpkdb8cej=AMs2kO1Vks-WYeae+CtAW2YOCc+Pz3E49mcrDQ@mail.gmail.com>
Hi Linus,
On 24/11/2016 15:17, Linus Walleij wrote:
> On Wed, Nov 23, 2016 at 3:11 PM, Quentin Schulz
> <quentin.schulz@free-electrons.com> wrote:
>
>> The GPIOs present in the AXP209 PMIC have multiple functions. They
>> typically allow a pin to be used as GPIO input or output and can also be
>> used as ADC or regulator for example.[1]
>>
>> This adds the possibility to use all functions of the GPIOs present in
>> the AXP209 PMIC thanks to pinctrl subsystem.
>>
>> [1] see registers 90H, 92H and 93H at
>> http://dl.linux-sunxi.org/AXP/AXP209_Datasheet_v1.0en.pdf
>>
>> Signed-off-by: Quentin Schulz <quentin.schulz@free-electrons.com>
>
> I need Maxime's review on this patch.
>
>> .../devicetree/bindings/gpio/gpio-axp209.txt | 28 +-
>
> Also move the bindings to pinctrl/pinctrl-axp209.txt
>
>> drivers/gpio/gpio-axp209.c | 551 ++++++++++++++++++---
>
> Combined drivers should be in drivers/pinctrl/*.
>
> Make a separate patch moving the driver to
> drivers/pinctrl/pinctrl-axp209.c (remember -M to git format-patch)
> augment Kconfig and Makefile in both subsystems and make
> these patches on top of that.
>
So basically:
- first patch for adding pinctrl to the existing driver
- second patch for moving the driver and binding from gpio to pinctrl
subsystem
- third patch for both removing Kconfig entry and Makefile rule from
gpio subsystem, and adding a Kconfig entry and a Makefile rule in
pinctrl subsystem
Is that what you want?
Thanks,
Quentin
> I will deal with cross-merging the result between the GPIO
> and pin control trees.
>
> Yours,
> Linus Walleij
>
--
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH V8 2/6] thermal: bcm2835: add thermal driver for bcm2835 soc
From: Eric Anholt @ 2016-11-29 22:12 UTC (permalink / raw)
To: Eduardo Valentin
Cc: Mark Rutland, devicetree, Florian Fainelli, Russell King,
Pawel Moll, Stephen Warren, Catalin Marinas, linux-pm, Lee Jones,
Will Deacon, Rob Herring, linux-rpi-kernel, Martin Sperl,
Zhang Rui, linux-arm-kernel
In-Reply-To: <20161129013436.GA3080@localhost.localdomain>
[-- Attachment #1.1: Type: text/plain, Size: 574 bytes --]
Eduardo Valentin <edubezval@gmail.com> writes:
> Hello Eric, Martin,
>
> On Mon, Nov 28, 2016 at 12:30:38PM -0800, Eric Anholt wrote:
>> Either the device was initialized by the firmware before handing off to
>> ARM (today's firmware) or it never will be (potential future firmware).
>
> And do you have a way to check if the firmware has the initialization
> code or not? By firmware version, for example. Or even, chip version,
> maybe?
We would know if it's not present because the register would be in its
power-on reset state, which is what the code is checking for.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3
From: Maxime Ripard @ 2016-11-29 21:59 UTC (permalink / raw)
To: Jean-Francois Moine
Cc: Icenowy Zheng, Chen-Yu Tsai, Jernej Skrabec,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <20161128114218.14d2ed434802a20fa6b62023-GANU6spQydw@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1321 bytes --]
On Mon, Nov 28, 2016 at 11:42:18AM +0100, Jean-Francois Moine wrote:
> On Mon, 28 Nov 2016 17:59:00 +0800
> Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org> wrote:
>
> > As there's currently a fork of U-Boot which provides simplefb support
> > for H3, a simplefb node can be added to the device tree.
> >
> > Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
> > ---
> >
> > I'm still not sure which pipeline should I use.
> >
> > And, it seems that HDMI Slow Clock is not needed?
> >
> > (seems that it's only for EDID, but simplefb won't use EDID)
>
> So, I don't see how this may work.
> How can the u-boot know the resolutions of the HDMI display device?
>
> In other words: I have a new H3 board with the last u-boot and kernel.
> I plug my (rather old or brand new) HDMI display device.
> After powering on the system, I hope to get something on the screen.
> How?
If it works like the driver for the first display engine in U-Boot, it
will use the preferred mode reported by the EDID, and will fallback to
1024x768 if it cannot access it.
Maybe it would be worth exchanging on the EDID code that has been done
for the u-boot driver too, so that it can be fixed in your driver.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v6 3/5] ARM: dts: sun8i-h3: add HDMI video nodes
From: Maxime Ripard @ 2016-11-29 21:57 UTC (permalink / raw)
To: Jean-Francois Moine
Cc: Icenowy Zheng, Dave Airlie, Rob Herring,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
In-Reply-To: <20161125112213.83420594eb435b6bb1a4d164-GANU6spQydw@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2524 bytes --]
On Fri, Nov 25, 2016 at 11:22:13AM +0100, Jean-Francois Moine wrote:
> On Fri, 25 Nov 2016 17:41:51 +0800
> Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org> wrote:
>
> > After removing CLK_PLL_DE's assigned-clock, the kernel passes compilation.
>
> The 'pll-de' and 'de' must have a fixed rate. Otherwise, if you do not
> use the legacy u-boot, I don't know which can be the rate of the DE.
>
> > However, it cannot recognize any HDMI screen...
> >
> > (My board is Orange Pi One, and I manually added status="okay"; to &lcd0, &de, &hdmi)
> >
> > [ 16.507802] sun8i-de2 1000000.de-controller: bound 1c0c000.lcd-controller (ops de2_lcd_ops [sun8i_de2_drm])
> > [ 16.675948] sun8i-de2 1000000.de-controller: bound 1ee0000.hdmi (ops de2_hdmi_fini [sun8i_de2_hdmi])
> > [ 16.685120] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> > [ 16.695876] [drm] No driver support for vblank timestamp query.
> > [ 16.701862] sun8i-de2 1000000.de-controller: No connectors reported connected with modes
> > [ 16.713061] [drm] Cannot find any crtc or sizes - going 1024x768
> > [ 16.734214] Console: switching to colour frame buffer device 128x48
> > [ 16.751022] sun8i-de2 1000000.de-controller: fb0: frame buffer device
>
> I put a 'pr_warn' message is case the EDID cannot be read.
> Have you this message?
>
> Anyway, there is a problem with the EDID:
> - my Orange Pi 2 (H3) randomly fails to read it. But this succeeds after
> rebooting once or twice.
> - my Banana Pi M2+ (H3) reads it correctly each time.
> - my Banana Pi M3 (A83T) can never read it.
>
> BTW, on first tries, I was forcing a CEA mode thru the kernel command
> line. This was working with the OPi2 and BPiM3, but there was no sound.
> In the last version, I use a EDID in edid_firmware for having sound
> with the BPiM3. This works fine.
> But, forcing a CEA mode is no more possible, so, when the OPi2 cannot
> read the EDID, the system switches to a VGA mode (default 1024x768)
> which is not supported. It seems that this is your case.
>
> So, in brief, if your board cannot read the EDID, put a EDID somewhere
> and its path in /sys/module/drm_kms_helper/parameters/edid_firmware.
> There will be no console, but X11 will work correctly.
This is one of the things that are usually very helpful to put in a
cover letter. This is obviously also a blocker for the merge of the
driver, and should be dealt with.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v2 1/2] eeprom: Add IDT 89HPESx EEPROM/CSR driver
From: Serge Semin @ 2016-11-29 21:45 UTC (permalink / raw)
To: Greg KH
Cc: srinivas.kandagatla, andrew, robh+dt, mark.rutland, Sergey.Semin,
linux-kernel, devicetree
In-Reply-To: <20161129212412.GA20334@kroah.com>
On Tue, Nov 29, 2016 at 10:24:12PM +0100, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Wed, Nov 30, 2016 at 12:16:25AM +0300, Serge Semin wrote:
> > On Tue, Nov 29, 2016 at 08:37:50PM +0100, Greg KH <gregkh@linuxfoundation.org> wrote:
> > > On Tue, Nov 29, 2016 at 01:38:20AM +0300, Serge Semin wrote:
> > > > +struct idt_89hpesx_dev {
> > > > + u32 eesize;
> > > > + bool eero;
> > > > + u8 eeaddr;
> > > > +
> > > > + u8 inieecmd;
> > > > + u8 inicsrcmd;
> > > > + u8 iniccode;
> > > > +
> > > > + atomic_t csr;
> > > > +
> > > > + int (*smb_write)(struct idt_89hpesx_dev *, const struct idt_smb_seq *);
> > > > + int (*smb_read)(struct idt_89hpesx_dev *, struct idt_smb_seq *);
> > > > + struct mutex smb_mtx;
> > > > +
> > > > + struct i2c_client *client;
> > > > +
> > > > + struct bin_attribute *ee_file;
> > > > + struct dentry *csr_dir;
> > > > + struct dentry *csr_file;
> > > > +};
> > > > +#define to_pdev_kobj(__kobj) \
> > > > + dev_get_drvdata(container_of(__kobj, struct device, kobj))
> > >
> > > Is it a struct device, or a kobject? This is totally confusing to me.
> > >
> > > And can't you just use kobj_to_dev()?
> > >
> >
> > I just didn't know about kobj_to_dev() inline function. Totally agree that
> > container_of() should be replaced with it.
> > What does look confusing to you? Do you mean the name "to_pdev_kobj" of the
> > macro?
>
> Yes, the macro is odd. As you are doing two different things here, just
> spell it out in the code and use kobj_to_dev() to make it easier to
> read please.
>
> > > > +/*
> > > > + * eeprom_attribute - EEPROM sysfs-node attributes
> > > > + *
> > > > + * NOTE Size will be changed in compliance with OF node. EEPROM attribute will
> > > > + * be read-only as well if the corresponding flag is specified in OF node.
> > > > + */
> > > > +BIN_ATTR(eeprom, 0644, idt_sysfs_eeprom_read, idt_sysfs_eeprom_write,
> > > > + EEPROM_DEF_SIZE);
> > >
> > > static?
> > >
> > > And BIN_ATTR_RW()?
> > >
> > > thanks,
> > >
> > > greg k-h
> >
> > Of course it should be static. Thanks for noticing that.
> > But I intentionally utilized BIN_ATTR() instead of BIN_ATTR_RW(), because
> > the last one implies to define the read/write methods with names
> > "_name##_read"/"_name##_write", which totally get out of naming within the
> > driver source code.
>
> That's ok, use the names the macro wants you to, that's the best way,
> and it ensures that I don't have to audit your permissions are correct
> for the file.
>
> > To tell the truth macro BIN_ATTR_RW() isn't that popular in the
> > kernel.
>
> Yes, but it should be, I have patches floating around somewhere to fix
> almost all of these up.
>
> > Neither is BIN_ATTR() macro, but it suites my driver better than the
> > another one.
>
> a "raw" BIN_ATTR() shouldn't be used either, please use the _RW()
> variant.
>
> thanks,
>
> greg k-h
Agreed with all the notes. I will send patchset v3 within next hour.
Thanks,
-Sergey
^ permalink raw reply
* Re: Re: [RFC PATCH] ARM: dts: sun8i: add simplefb node for H3
From: Maxime Ripard @ 2016-11-29 21:43 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Icenowy Zheng, Jernej Skrabec, Jean-Francois Moine, devicetree,
linux-arm-kernel, linux-kernel, linux-sunxi
In-Reply-To: <CAGb2v66yQ2d=12P_MYyQXTfcZnNAMcb+0i=NEab4sNcJZUyL-w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]
On Mon, Nov 28, 2016 at 06:24:24PM +0800, Chen-Yu Tsai wrote:
> On Mon, Nov 28, 2016 at 6:19 PM, Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org> wrote:
> >
> >
> > 28.11.2016, 18:07, "Chen-Yu Tsai" <wens-jdAy2FN1RRM@public.gmane.org>:
> >> On Mon, Nov 28, 2016 at 5:59 PM, Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org> wrote:
> >>> As there's currently a fork of U-Boot which provides simplefb support
> >>
> >> Please add it when its finalized...
> >>
> >>> for H3, a simplefb node can be added to the device tree.
> >>>
> >>> Signed-off-by: Icenowy Zheng <icenowy-ymACFijhrKM@public.gmane.org>
> >>> ---
> >>>
> >>> I'm still not sure which pipeline should I use.
> >>
> >> You are supposed to add _all_ the pipelines that are available and
> >> supported by U-boot. U-boot is then supposed to enable and update
> >> the one it set up.
> >
> > I mean the pipeline string ;-)
>
> Looks good to me. There's no separate frontend/backend in DE 2.0.
It looks good to me too.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v7 0/8] drm: sun8i: Add DE2 HDMI video support
From: Maxime Ripard @ 2016-11-29 21:36 UTC (permalink / raw)
To: Jean-Francois Moine
Cc: Dave Airlie, Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Laurent Pinchart
In-Reply-To: <cover.1480414715.git.moinejf-GANU6spQydw@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1561 bytes --]
On Tue, Nov 29, 2016 at 11:18:35AM +0100, Jean-Francois Moine wrote:
> This patchset series adds HDMI video support to the Allwinner
> sun8i SoCs which include the display engine 2 (DE2).
> The driver contains the code for the A83T and H3 SoCs, and
> some H3 boards, but it could be used/extended for other SoCs
> (A64, H2, H5) and boards (Banana PIs, Orange PIs).
Honestly, I'm getting a bit worried by the fact that you ignore
reviews.
On the important reviews that you got that are to be seen as major
issues that block the inclusion, we have:
- The fact that the HDMI driver is actually just a designware IP,
and while you should use the driver that already exists, you just
duplicated all that code.
- The fact that you ignored Rob (v6) and I (v5) comment on using OF
graph to model the connection between the display engine and the
TCON. Something that Laurent also pointed out in this version.
- The fact that you ignored that you needed an HDMI connector node
as a child of the HDMI controller. This has been reported by Rob
(v6) and yet again in this version by Laurent.
- And finally the fact that we can't have several display engine in
parallel, if needs be. This has happened in the past already on
Allwinner SoCs, so it's definitely something we should consider in
the DT bindings, since we can't break them.
Until those are fixed, I cannot see how this driver can be merged,
unfortunately.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [PATCH v4] clkdev: add devm_of_clk_get()
From: Stephen Boyd @ 2016-11-29 21:26 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: Russell King - ARM Linux, Rob Herring, Linux-ALSA, Linux-DT,
Michael Turquette, Linux-Kernel, Mark Brown, linux-clk, Linux-ARM
In-Reply-To: <87zikjw08i.wl%kuninori.morimoto.gx@renesas.com>
On 11/29, Kuninori Morimoto wrote:
>
> From: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>
> Current Linux has of_clk_get(), but doesn't have devm_of_clk_get().
> This patch adds it. It is implemeted in clk-devres.c to share
> devm_clk_release().
Please add an explanation of why we want this sort of API. The
example you gave for audio sound card is useful. We're not going
to remember 5 months from now why we did something, so we should
put that here instead of digging through mailing list archives.
>
> Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
>
> diff --git a/drivers/clk/clk-devres.c b/drivers/clk/clk-devres.c
> index 8f57154..2449b25 100644
> --- a/drivers/clk/clk-devres.c
> +++ b/drivers/clk/clk-devres.c
> @@ -53,3 +53,24 @@ void devm_clk_put(struct device *dev, struct clk *clk)
> WARN_ON(ret);
> }
> EXPORT_SYMBOL(devm_clk_put);
> +
> +struct clk *devm_of_clk_get(struct device *dev,
> + struct device_node *np, int index)
Please call this devm_get_clk_from_child() instead. Also, replace
the index argument with a string called con_id. Then call
of_clk_get_by_name() instead of of_clk_get().
> +{
> + struct clk **ptr, *clk;
> +
> + ptr = devres_alloc(devm_clk_release, sizeof(*ptr), GFP_KERNEL);
> + if (!ptr)
> + return ERR_PTR(-ENOMEM);
> +
> + clk = of_clk_get(np, index);
> + if (!IS_ERR(clk)) {
> + *ptr = clk;
> + devres_add(dev, ptr);
> + } else {
> + devres_free(ptr);
> + }
> +
> + return clk;
> +}
> +EXPORT_SYMBOL(devm_of_clk_get);
> diff --git a/include/linux/clk.h b/include/linux/clk.h
> index 123c027..7f50c5f 100644
> --- a/include/linux/clk.h
> +++ b/include/linux/clk.h
> @@ -17,8 +17,9 @@
> #include <linux/notifier.h>
>
> struct device;
> -
> struct clk;
> +struct device_node;
> +struct of_phandle_args;
>
> /**
> * DOC: clk notifier callback types
> @@ -249,6 +250,21 @@ static inline void clk_unprepare(struct clk *clk)
> struct clk *devm_clk_get(struct device *dev, const char *id);
>
> /**
> + * devm_clk_get - lookup and obtain a managed reference to a clock producer.
That doesn't even match the name of the function.
> + * @dev: device for clock "consumer"
> + * @np: pointer to clock consumer node
> + * @index: clock index
> + *
> + * This function parses the clocks, and uses them to look up the
> + * struct clk from the registered list of clock providers by using
> + * @np and @index.
> + *
> + * The clock will automatically be freed when the device is unbound
> + * from the bus.
> + */
> +struct clk *devm_of_clk_get(struct device *dev, struct device_node *np, int index);
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v2 1/2] eeprom: Add IDT 89HPESx EEPROM/CSR driver
From: Greg KH @ 2016-11-29 21:24 UTC (permalink / raw)
To: Serge Semin
Cc: srinivas.kandagatla, andrew, robh+dt, mark.rutland, Sergey.Semin,
linux-kernel, devicetree
In-Reply-To: <20161129211625.GB9146@mobilestation>
On Wed, Nov 30, 2016 at 12:16:25AM +0300, Serge Semin wrote:
> On Tue, Nov 29, 2016 at 08:37:50PM +0100, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Tue, Nov 29, 2016 at 01:38:20AM +0300, Serge Semin wrote:
> > > +struct idt_89hpesx_dev {
> > > + u32 eesize;
> > > + bool eero;
> > > + u8 eeaddr;
> > > +
> > > + u8 inieecmd;
> > > + u8 inicsrcmd;
> > > + u8 iniccode;
> > > +
> > > + atomic_t csr;
> > > +
> > > + int (*smb_write)(struct idt_89hpesx_dev *, const struct idt_smb_seq *);
> > > + int (*smb_read)(struct idt_89hpesx_dev *, struct idt_smb_seq *);
> > > + struct mutex smb_mtx;
> > > +
> > > + struct i2c_client *client;
> > > +
> > > + struct bin_attribute *ee_file;
> > > + struct dentry *csr_dir;
> > > + struct dentry *csr_file;
> > > +};
> > > +#define to_pdev_kobj(__kobj) \
> > > + dev_get_drvdata(container_of(__kobj, struct device, kobj))
> >
> > Is it a struct device, or a kobject? This is totally confusing to me.
> >
> > And can't you just use kobj_to_dev()?
> >
>
> I just didn't know about kobj_to_dev() inline function. Totally agree that
> container_of() should be replaced with it.
> What does look confusing to you? Do you mean the name "to_pdev_kobj" of the
> macro?
Yes, the macro is odd. As you are doing two different things here, just
spell it out in the code and use kobj_to_dev() to make it easier to
read please.
> > > +/*
> > > + * eeprom_attribute - EEPROM sysfs-node attributes
> > > + *
> > > + * NOTE Size will be changed in compliance with OF node. EEPROM attribute will
> > > + * be read-only as well if the corresponding flag is specified in OF node.
> > > + */
> > > +BIN_ATTR(eeprom, 0644, idt_sysfs_eeprom_read, idt_sysfs_eeprom_write,
> > > + EEPROM_DEF_SIZE);
> >
> > static?
> >
> > And BIN_ATTR_RW()?
> >
> > thanks,
> >
> > greg k-h
>
> Of course it should be static. Thanks for noticing that.
> But I intentionally utilized BIN_ATTR() instead of BIN_ATTR_RW(), because
> the last one implies to define the read/write methods with names
> "_name##_read"/"_name##_write", which totally get out of naming within the
> driver source code.
That's ok, use the names the macro wants you to, that's the best way,
and it ensures that I don't have to audit your permissions are correct
for the file.
> To tell the truth macro BIN_ATTR_RW() isn't that popular in the
> kernel.
Yes, but it should be, I have patches floating around somewhere to fix
almost all of these up.
> Neither is BIN_ATTR() macro, but it suites my driver better than the
> another one.
a "raw" BIN_ATTR() shouldn't be used either, please use the _RW()
variant.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v5 1/3] i2c: pxa: Add support for the I2C units found in Armada 3700
From: Wolfram Sang @ 2016-11-29 21:17 UTC (permalink / raw)
To: Romain Perier
Cc: Wolfram Sang, linux-i2c, devicetree, Rob Herring, Ian Campbell,
Pawel Moll, Mark Rutland, Kumar Gala, linux-arm-kernel,
Jason Cooper, Andrew Lunn, Sebastian Hesselbarth, Gregory Clement,
Thomas Petazzoni, Nadav Haklai, Omri Itach, Shadi Ammouri,
Yahuda Yitschak, Hanna Hawa, Neta Zur Hershkovits
In-Reply-To: <20161121133247.29889-2-romain.perier@free-electrons.com>
[-- Attachment #1: Type: text/plain, Size: 1060 bytes --]
> + if (of_device_is_compatible(np, "marvell,armada-3700-i2c")) {
> + i2c->fm_mask = ICR_BUSMODE_FM;
> + i2c->hs_mask = ICR_BUSMODE_HS;
> + } else {
> + i2c->fm_mask = ICR_FM;
> + i2c->hs_mask = ICR_HS;
> + }
>
> *i2c_types = (enum pxa_i2c_types)(of_id->data);
>
> @@ -1181,6 +1194,13 @@ static int i2c_pxa_probe_pdata(struct platform_device *pdev,
> i2c->master_code = 0xe;
> i2c->rate = plat->rate;
> }
> + if (!strcmp(id->name, "armada-3700-i2c")) {
> + i2c->fm_mask = ICR_BUSMODE_FM;
> + i2c->hs_mask = ICR_BUSMODE_HS;
> + } else {
> + i2c->fm_mask = ICR_FM;
> + i2c->hs_mask = ICR_HS;
> + }
Okay, having the same code twice is not nice as well.
Sorry for missing this in the first review and going a step back, but I
think now the best solution is to have again a REGS_A3700 struct, but we
should extend it with new entries for the shifted bits. Then in the init
code, you can do something like:
i2c->fm_mask = pxa_reg_layout[i2c_type].fm_mask ?: ICR_FM;
Makes sense?
Thanks,
Wolfram
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/2] eeprom: Add IDT 89HPESx EEPROM/CSR driver
From: Serge Semin @ 2016-11-29 21:16 UTC (permalink / raw)
To: Greg KH
Cc: srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A, andrew-g2DYL2Zd6BY,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
Sergey.Semin-vHJ8rsvMqnUPfZBKTuL5GA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161129193750.GD20341-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
On Tue, Nov 29, 2016 at 08:37:50PM +0100, Greg KH <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org> wrote:
> On Tue, Nov 29, 2016 at 01:38:20AM +0300, Serge Semin wrote:
> > +struct idt_89hpesx_dev {
> > + u32 eesize;
> > + bool eero;
> > + u8 eeaddr;
> > +
> > + u8 inieecmd;
> > + u8 inicsrcmd;
> > + u8 iniccode;
> > +
> > + atomic_t csr;
> > +
> > + int (*smb_write)(struct idt_89hpesx_dev *, const struct idt_smb_seq *);
> > + int (*smb_read)(struct idt_89hpesx_dev *, struct idt_smb_seq *);
> > + struct mutex smb_mtx;
> > +
> > + struct i2c_client *client;
> > +
> > + struct bin_attribute *ee_file;
> > + struct dentry *csr_dir;
> > + struct dentry *csr_file;
> > +};
> > +#define to_pdev_kobj(__kobj) \
> > + dev_get_drvdata(container_of(__kobj, struct device, kobj))
>
> Is it a struct device, or a kobject? This is totally confusing to me.
>
> And can't you just use kobj_to_dev()?
>
I just didn't know about kobj_to_dev() inline function. Totally agree that
container_of() should be replaced with it.
What does look confusing to you? Do you mean the name "to_pdev_kobj" of the
macro?
> > +/*
> > + * eeprom_attribute - EEPROM sysfs-node attributes
> > + *
> > + * NOTE Size will be changed in compliance with OF node. EEPROM attribute will
> > + * be read-only as well if the corresponding flag is specified in OF node.
> > + */
> > +BIN_ATTR(eeprom, 0644, idt_sysfs_eeprom_read, idt_sysfs_eeprom_write,
> > + EEPROM_DEF_SIZE);
>
> static?
>
> And BIN_ATTR_RW()?
>
> thanks,
>
> greg k-h
Of course it should be static. Thanks for noticing that.
But I intentionally utilized BIN_ATTR() instead of BIN_ATTR_RW(), because
the last one implies to define the read/write methods with names
"_name##_read"/"_name##_write", which totally get out of naming within the
driver source code. To tell the truth macro BIN_ATTR_RW() isn't that
popular in the kernel. Neither is BIN_ATTR() macro, but it suites my driver
better than the another one.
Thanks,
-Sergey
--
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 2/2] eeprom: Add IDT 89HPESx driver bindings file
From: Serge Semin @ 2016-11-29 21:15 UTC (permalink / raw)
To: Greg KH
Cc: srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A, andrew-g2DYL2Zd6BY,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
Sergey.Semin-vHJ8rsvMqnUPfZBKTuL5GA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161129193436.GB20341-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
On Tue, Nov 29, 2016 at 08:34:36PM +0100, Greg KH <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org> wrote:
> On Tue, Nov 29, 2016 at 01:38:21AM +0300, Serge Semin wrote:
> > See cover-letter for changelog
>
> There is no cover letter in an individual patch when it gets committed
> to the tree...
>
> So please fix, personally, I never read cover letters, each patch should
> be "obvious" on it's own :)
>
> thanks,
>
> greg k-h
Understood. I'll send the v3 of altered patchset over with individual messages
for each patch.
Thanks,
-Sergey
--
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 0/3] increase TSCADC clock to 24MHz and fix ti,charge-delay to represent in nS
From: Dmitry Torokhov @ 2016-11-29 21:09 UTC (permalink / raw)
To: Mugunthan V N
Cc: Lee Jones, linux-input, Jonathan Cameron, Rob Herring,
Mark Rutland, Sekhar Nori, Vignesh R, devicetree, linux-omap,
linux-kernel
In-Reply-To: <8b97b7e6-1ea4-bf13-7da5-55135a994231@ti.com>
On Tue, Nov 29, 2016 at 11:11:35AM +0530, Mugunthan V N wrote:
> On Friday 25 November 2016 03:29 PM, Lee Jones wrote:
> > On Fri, 25 Nov 2016, Mugunthan V N wrote:
> >
> >> Hi Dmitry Torokhov,
> >>
> >> On Thursday 10 November 2016 10:05 PM, Mugunthan V N wrote:
> >>> This patch series enables ADC to be clocked at 24MHz as the
> >>> TI AM335x ADC driver has already adopted to use DMA to transfer
> >>> ADC samples. Now ADC can generated upto 800K Samples per second
> >>> with the patch [1] on AM335x BBB and AM437x GP EVM.
> >>>
> >>> when ADC ref clock is set at 24MHz, I am seeing some issue with
> >>> touch screen pointer as the pointer jumps to random locations
> >>> with free draw application. The issue is due to increase in ADC
> >>> clock and charge delay for the touchscreen ADC line duration
> >>> reduced.
> >>>
> >>> So the notation of ti,charge-delay in terms of ADC clock is
> >>> wrong, it has to be represented in time and driver has to convert
> >>> the charge delay time to ADC clocks based on what ADC clock
> >>> frequency is set.
> >>>
> >>> Measured the performance with the iio_generic_buffer with the
> >>> patch [2] applied
> >>>
> >>> Verified the touch screen on AM335x GP EVM and AM335x BBB LCD7
> >>> cape with [3] dts for display and touch screen to work.
> >>>
> >>
> >> Since there are acks from DT and MFD maintainers, can you pull the patch
> >> series if you do not have any more comments.
> >
> > Cant do anything without *all* Acks.
> >
> Hi Dmitry Torokhov,
>
> Can you provide your inputs on the patch series.
You have my ack for the input bit.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 2/3] Input: ti_am335x_tsc: Add support for ti,charge-delay-ns
From: Dmitry Torokhov @ 2016-11-29 21:09 UTC (permalink / raw)
To: Mugunthan V N
Cc: linux-input-u79uwXL29TY76Z2rM5mHXA, Jonathan Cameron, Rob Herring,
Mark Rutland, Lee Jones, Sekhar Nori, Vignesh R,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20161111075819.5760-1-mugunthanvnm-l0cyMroinI0@public.gmane.org>
On Fri, Nov 11, 2016 at 01:28:19PM +0530, Mugunthan V N wrote:
> ti,charge-delay will be deprecated as it represents number of
> clock cycles and the DT entries are done in assumption of 3MHz
> TSCADC clock, but clock can be set upto 24MHz. So driver add
> support for ti,charge-delay-ns and do not drop support for
> ti,charge-delay to support old dtbs and it will be assumed that
> it is for 3MHz TSCADC clock and will be calculated as per current
> clock speed.
>
> Signed-off-by: Mugunthan V N <mugunthanvnm-l0cyMroinI0@public.gmane.org>
Acked-by: Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> drivers/input/touchscreen/ti_am335x_tsc.c | 31 +++++++++++++++++++++++--------
> 1 file changed, 23 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/input/touchscreen/ti_am335x_tsc.c b/drivers/input/touchscreen/ti_am335x_tsc.c
> index 7953381d939a..104b3640f728 100644
> --- a/drivers/input/touchscreen/ti_am335x_tsc.c
> +++ b/drivers/input/touchscreen/ti_am335x_tsc.c
> @@ -379,15 +379,30 @@ static int titsc_parse_dt(struct platform_device *pdev,
> ts_dev->coordinate_readouts = 5;
> }
>
> - err = of_property_read_u32(node, "ti,charge-delay",
> + err = of_property_read_u32(node, "ti,charge-delay-ns",
> &ts_dev->charge_delay);
> - /*
> - * If ti,charge-delay value is not specified, then use
> - * CHARGEDLY_OPENDLY as the default value.
> - */
> - if (err < 0) {
> - ts_dev->charge_delay = CHARGEDLY_OPENDLY;
> - dev_warn(&pdev->dev, "ti,charge-delay not specified\n");
> + if (err >= 0) {
> + u64 charge_delay = ts_dev->charge_delay;
> +
> + charge_delay *= ADC_CLK;
> + do_div(charge_delay, 1E9);
> + ts_dev->charge_delay = (u32)charge_delay;
> + } else {
> + err = of_property_read_u32(node, "ti,charge-delay",
> + &ts_dev->charge_delay);
> + /*
> + * If ti,charge-delay value is not specified, then use
> + * CHARGEDLY_OPENDLY as the default value.
> + */
> + if (err < 0) {
> + ts_dev->charge_delay = CHARGEDLY_OPENDLY;
> + dev_warn(&pdev->dev, "ti,charge-delay not specified\n");
> + }
> + /*
> + * ti,charge-delay is specified with referrence to 3MHz,
> + * so convert it to in referrence to current clock
> + */
> + ts_dev->charge_delay *= ADC_CLK / 3000000;
> }
>
> return of_property_read_u32_array(node, "ti,wire-config",
> --
> 2.11.0.rc0.7.gbe5a750
>
--
Dmitry
--
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: [alsa-devel] [PATCH v2] clkdev: add devm_of_clk_get()
From: Stephen Boyd @ 2016-11-29 21:05 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: Rob Herring, Linux-ALSA, Linux-DT, Michael Turquette,
Russell King, Linux-Kernel, Mark Brown,
linux-clk-u79uwXL29TY76Z2rM5mHXA, Linux-ARM
In-Reply-To: <87y409cw71.wl%kuninori.morimoto.gx-zM6kxYcvzFBBDgjK7y7TUQ@public.gmane.org>
On 11/24, Kuninori Morimoto wrote:
>
> Hi Stephen, again
>
> > > I've seen bindings that have the 'clocks' property at the top
> > > level and the appropriate 'clock-names' property to relate the
> > > clocks to a subnode.
> > >
> > > sound_soc {
> > > clocks = <&xxx>, <&xxx>;
> > > clock-names = "cpu", "codec";
> > > ...
> > > cpu {
> > > ...
> > > };
> > > codec {
> > > ...
> > > };
> > > };
> > >
> > > Then the subnodes call clk_get() with the top level device and
> > > the name of their node and things match up. I suppose this
> > > binding is finalized though, so we can't really do that?
> > >
> > > I see that the gpio framework has a similar design called
> > > devm_get_gpiod_from_child(), so how about we add a
> > > devm_get_clk_from_child() API? That would more closely match the
> > > intent here, which is to restrict the clk_get() operation to
> > > child nodes of the device passed as the first argument.
> > >
> > > struct clk *devm_get_clk_from_child(struct device *dev,
> > > const char *con_id,
> > > struct device_node *child);
>
> Thanks, but, my point is that Linux already have "of_clk_get()",
> but we don't have its devm_ version.
> The point is that of_clk_get() can get clock from "device_node".
> Why having devm_ version become so problem ?
The problem is that it encourages the use of of_clk_get() when
clk_get() is more desirable. Ideally of_clk_get() is never used
when a device exists. In this case, it seems like we need to
support it though, hence the suggestion of having a
devm_get_clk_from_child() API, that explicitly reads as "get a
clock from a child node of this device". The distinction is
important, because of_clk_get() should rarely be used.
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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
* [PATCH] arm64: dts: juno: Correct PCI IO window
From: Jeremy Linton @ 2016-11-29 20:45 UTC (permalink / raw)
To: devicetree-u79uwXL29TY76Z2rM5mHXA
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
liviu.dudau-5wv7dgnIgG8, sudeep.holla-5wv7dgnIgG8,
lorenzo.pieralisi-5wv7dgnIgG8, robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
mark.rutland-5wv7dgnIgG8, catalin.marinas-5wv7dgnIgG8,
will.deacon-5wv7dgnIgG8
The PCIe root complex on Juno translates the MMIO mapped
at 0x5f800000 to the PIO address range starting at 0
(which is common because PIO addresses are generally < 64k).
Correct the DT to reflect this.
Signed-off-by: Jeremy Linton <jeremy.linton-5wv7dgnIgG8@public.gmane.org>
---
arch/arm64/boot/dts/arm/juno-base.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/arm/juno-base.dtsi b/arch/arm64/boot/dts/arm/juno-base.dtsi
index 334271a..7d3a2ac 100644
--- a/arch/arm64/boot/dts/arm/juno-base.dtsi
+++ b/arch/arm64/boot/dts/arm/juno-base.dtsi
@@ -393,7 +393,7 @@
#address-cells = <3>;
#size-cells = <2>;
dma-coherent;
- ranges = <0x01000000 0x00 0x5f800000 0x00 0x5f800000 0x0 0x00800000>,
+ ranges = <0x01000000 0x00 0x00000000 0x00 0x5f800000 0x0 0x00800000>,
<0x02000000 0x00 0x50000000 0x00 0x50000000 0x0 0x08000000>,
<0x42000000 0x40 0x00000000 0x40 0x00000000 0x1 0x00000000>;
#interrupt-cells = <1>;
--
2.5.5
--
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
* Re: [PATCH v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI
From: Laurent Pinchart @ 2016-11-29 20:10 UTC (permalink / raw)
To: Jean-Francois Moine
Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Dave Airlie,
Maxime Ripard, Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161129210455.d0c8450d3ceb83c1abe521b0-GANU6spQydw@public.gmane.org>
Hi Jean-François,
On Tuesday 29 Nov 2016 21:04:55 Jean-Francois Moine wrote:
> On Tue, 29 Nov 2016 21:33 +0200 Laurent Pinchart wrote:
> >>> You need a third port for the HDMI encoder output, connected to an
> >>> HDMI connector DT node.
> >>
> >> I don't see what you mean. The HDMI device is both the encoder
> >> and connector (as the TDA998x):
> >
> > The driver might create both an encoder and a connector, but I very much
> > doubt that the "allwinner,sun8i-a83t-hdmi" hardware contains a connector,
> > unless the SoC package has an HDMI connector coming out of it :-)
> >
> >> plane -> DE2 mixer ---> TCON -----> HDMI -----> display device
> >> ----- plane ------ - CRTC - - encoder \
> >> connector -- (HDMI cable)
> >> audio-controller - - audio-codec /
>
> The schema is the same as the Dove Cubox: the TDA998x is just a chip
> with some wires going out and the physical connector is supposed to be
> at the end of the wires.
I've missed the Dove Cubox DT bindings when they were submitted. Fortunately
(or unfortunately for you, depending on how you look at it ;-)) I've paid more
attention this time.
> Here, the HDMI pins of the SoC go to a pure hardware chip and then to
> the physical connector. Which software entity do you want to add?
I don't want to add a software entity, I just want to model the connector in
DT as it's present in the system. Even though that's more common for other bus
types than HDMI (LVDS for instance) it wouldn't be inconceivable to connect
the HDMI signals to an on-board chim instead of an HDMI connector, so the HDMI
encoder output should be modelled by a port and connected to a connector DT
node in this case.
--
Regards,
Laurent Pinchart
--
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 v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI
From: Jean-Francois Moine @ 2016-11-29 20:04 UTC (permalink / raw)
To: Laurent Pinchart
Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Dave Airlie,
Maxime Ripard, Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <6356753.Ekaj7GdA0W@avalon>
On Tue, 29 Nov 2016 21:33 +0200
Laurent Pinchart <laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org> wrote:
> > > You need a third port for the HDMI encoder output, connected to an HDMI
> > > connector DT node.
> >
> > I don't see what you mean. The HDMI device is both the encoder
> > and connector (as the TDA998x):
>
> The driver might create both an encoder and a connector, but I very much doubt
> that the "allwinner,sun8i-a83t-hdmi" hardware contains a connector, unless the
> SoC package has an HDMI connector coming out of it :-)
>
> > plane -> DE2 mixer ---> TCON -----> HDMI -----> display device
> > ----- plane ------ - CRTC - - encoder \
> > connector -- (HDMI cable)
> > audio-controller - - audio-codec /
The schema is the same as the Dove Cubox: the TDA998x is just a chip
with some wires going out and the physical connector is supposed to be
at the end of the wires.
Here, the HDMI pins of the SoC go to a pure hardware chip and then to
the physical connector. Which software entity do you want to add?
--
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef | http://moinejf.free.fr/
--
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 v2 1/2] eeprom: Add IDT 89HPESx EEPROM/CSR driver
From: Greg KH @ 2016-11-29 19:37 UTC (permalink / raw)
To: Serge Semin
Cc: srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A, andrew-g2DYL2Zd6BY,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
Sergey.Semin-vHJ8rsvMqnUPfZBKTuL5GA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1480372701-30560-2-git-send-email-fancer.lancer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Tue, Nov 29, 2016 at 01:38:20AM +0300, Serge Semin wrote:
> +struct idt_89hpesx_dev {
> + u32 eesize;
> + bool eero;
> + u8 eeaddr;
> +
> + u8 inieecmd;
> + u8 inicsrcmd;
> + u8 iniccode;
> +
> + atomic_t csr;
> +
> + int (*smb_write)(struct idt_89hpesx_dev *, const struct idt_smb_seq *);
> + int (*smb_read)(struct idt_89hpesx_dev *, struct idt_smb_seq *);
> + struct mutex smb_mtx;
> +
> + struct i2c_client *client;
> +
> + struct bin_attribute *ee_file;
> + struct dentry *csr_dir;
> + struct dentry *csr_file;
> +};
> +#define to_pdev_kobj(__kobj) \
> + dev_get_drvdata(container_of(__kobj, struct device, kobj))
Is it a struct device, or a kobject? This is totally confusing to me.
And can't you just use kobj_to_dev()?
> +/*
> + * eeprom_attribute - EEPROM sysfs-node attributes
> + *
> + * NOTE Size will be changed in compliance with OF node. EEPROM attribute will
> + * be read-only as well if the corresponding flag is specified in OF node.
> + */
> +BIN_ATTR(eeprom, 0644, idt_sysfs_eeprom_read, idt_sysfs_eeprom_write,
> + EEPROM_DEF_SIZE);
static?
And BIN_ATTR_RW()?
thanks,
greg k-h
--
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 v3 1/2] dt-bindings: drm/bridge: adv7511: Add regulator bindings
From: Laurent Pinchart @ 2016-11-29 19:37 UTC (permalink / raw)
To: Mark Brown; +Cc: devicetree, linux-arm-msm, dri-devel
In-Reply-To: <20161129110125.sksjxfy56ofzyxw3@sirena.org.uk>
Hi Mark,
On Tuesday 29 Nov 2016 11:01:25 Mark Brown wrote:
> On Tue, Nov 29, 2016 at 11:11:03AM +0200, Laurent Pinchart wrote:
> > On Tuesday 29 Nov 2016 13:41:33 Archit Taneja wrote:
> >> I thought we couldn't add mandatory properties once the device is
> >> already present in DT for one or more platforms.
> >
> > You can, as long as you treat them as optional in the driver to retain
> > backward compatibility. The DT bindings should document the properties
> > expected from a new platform (older versions of the bindings will always
> > be available in the git history).
>
> The device probably never worked without power... note that the kernel
> will substitute in dummy regulators for anything that isn't explicitly
> mapped so it won't actually break anything.
>
> >> Say, if we do make it mandatory for future additions, we would need to
> >> have DT property for the supplies for the new platforms. If the
> >> regulators on these boards are fixed supplies, they would be need to be
> >> modeled using "regulator-fixed", possibly without any input supply. Is
> >> that what you're suggesting?
> >
> > That's the idea, yes. Clock maintainers have a similar opinion regarding
> > the clock bindings, where a clock that is not optional at the hardware
> > level should be specified in DT even if it's always present.
> >
> > Mark, any opinion ?
>
> It's best practice to always describe the power. The kernel will cope
> if people don't but it's not unknown for drivers to discover a reason
> for wanting information about their power and hard to retrofit that if
> it's not been in there from the get go.
Sounds good to me, thanks.
> Please note that if you're going to CC me into a graphics thread there's
> a good chance I will miss it, I get copied on quite a lot of graphics
> related mail that's not really relevant so I often skip it. Changing
> the subject line would help with that.
I try to add a (CC'ing xxx) at the beginning of the e-mail to draw attention
when a question is targetted at a particular person. If that's not enough I
can change the subject, but might forget to do so from time to time. Or you
could whitelist me, unless I'm already blacklisted ;-)
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v2 1/2] eeprom: Add IDT 89HPESx EEPROM/CSR driver
From: Greg KH @ 2016-11-29 19:34 UTC (permalink / raw)
To: Serge Semin
Cc: srinivas.kandagatla, andrew, robh+dt, mark.rutland, Sergey.Semin,
linux-kernel, devicetree
In-Reply-To: <1480372701-30560-2-git-send-email-fancer.lancer@gmail.com>
On Tue, Nov 29, 2016 at 01:38:20AM +0300, Serge Semin wrote:
> See cover-letter for changelog
Same here.
^ permalink raw reply
* Re: [PATCH v2 2/2] eeprom: Add IDT 89HPESx driver bindings file
From: Greg KH @ 2016-11-29 19:34 UTC (permalink / raw)
To: Serge Semin
Cc: srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A, andrew-g2DYL2Zd6BY,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
Sergey.Semin-vHJ8rsvMqnUPfZBKTuL5GA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1480372701-30560-3-git-send-email-fancer.lancer-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Tue, Nov 29, 2016 at 01:38:21AM +0300, Serge Semin wrote:
> See cover-letter for changelog
There is no cover letter in an individual patch when it gets committed
to the tree...
So please fix, personally, I never read cover letters, each patch should
be "obvious" on it's own :)
thanks,
greg k-h
--
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 v7 4/8] drm/sunxi: Add DT bindings documentation of Allwinner HDMI
From: Laurent Pinchart @ 2016-11-29 19:33 UTC (permalink / raw)
To: Jean-Francois Moine
Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW, Dave Airlie,
Maxime Ripard, Rob Herring, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <20161129202751.e94f72a1b9e2c2fb064e9933-GANU6spQydw@public.gmane.org>
Hi Jean-François,
On Tuesday 29 Nov 2016 20:27:51 Jean-Francois Moine wrote:
> On Tue, 29 Nov 2016 20:46:22 +0200 Laurent Pinchart wrote:
> [snip]
>
> >> +Example:
> >> +
> >> + hdmi: hdmi@01ee0000 {
> >> + compatible = "allwinner,sun8i-a83t-hdmi";
> >> + reg = <0x01ee0000 0x20000>;
> >> + clocks = <&ccu CLK_BUS_HDMI>, <&ccu CLK_HDMI>,
> >> + <&ccu CLK_HDMI_DDC>;
> >> + clock-names = "bus", "clock", "ddc-clock";
> >> + resets = <&ccu RST_HDMI0>, <&ccu RST_HDMI1>;
> >> + reset-names = "hdmi0", "hdmi1";
> >> + pinctrl-names = "default";
> >> + pinctrl-0 = <&hdmi_pins_a>;
> >> + status = "disabled";
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> + port@0 { /* video */
> >> + reg = <0>;
> >> + hdmi_tcon1: endpoint {
> >> + remote-endpoint = <&tcon1_hdmi>;
> >> + };
> >> + };
> >> + port@1 { /* audio */
> >> + reg = <1>;
> >> + hdmi_i2s2: endpoint {
> >> + remote-endpoint = <&i2s2_hdmi>;
> >> + };
> >> + };
> >
> > You need a third port for the HDMI encoder output, connected to an HDMI
> > connector DT node.
>
> I don't see what you mean. The HDMI device is both the encoder
> and connector (as the TDA998x):
The driver might create both an encoder and a connector, but I very much doubt
that the "allwinner,sun8i-a83t-hdmi" hardware contains a connector, unless the
SoC package has an HDMI connector coming out of it :-)
> plane -> DE2 mixer ---> TCON -----> HDMI -----> display device
> ----- plane ------ - CRTC - - encoder \
> connector -- (HDMI cable)
> audio-controller - - audio-codec /
>
> > > + };
--
Regards,
Laurent Pinchart
--
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
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