Re: [PATCH 4.4 009/115] Bluetooth: btusb: driver to enable the usb-wakeup feature

On Fri, Dec 22, 2017 at 08:48:28AM +0100, Greg Kroah-Hartman wrote: > I've reverted this from 4.4 and 4.9-stable, but note that this was Thanks! > included in 4.14-rc1, so something needs to be done in Linus's tree to > resolve this issue, otherwise people will hit this as a regression when >

Re: [PATCH 4.4 75/78] Revert "Bluetooth: btusb: driver to enable the usb-wakeup feature"

it.k@intel.com> > Cc: Oliver Neukum <oneu...@suse.com> > Cc: Marcel Holtmann <mar...@holtmann.org> > Cc: Matthias Kaehlcke <m...@chromium.org> > Reported-by: Guenter Roeck <li...@roeck-us.net> > Reported-by: Brian Norris <briannor...@chromium.org>

Re: [PATCH 4.4 75/78] Revert "Bluetooth: btusb: driver to enable the usb-wakeup feature"

Kaehlcke > Reported-by: Guenter Roeck > Reported-by: Brian Norris > Signed-off-by: Greg Kroah-Hartman FWIW: Acked-by: Brian Norris Thanks for working past the confusion. > --- > drivers/bluetooth/btusb.c |5 - > 1 file changed, 5 deletions(-) > > --- a/driver

Re: [PATCH 4.4 009/115] Bluetooth: btusb: driver to enable the usb-wakeup feature

On Thu, Dec 21, 2017 at 07:05:03PM +, Ghorai, Sukumar wrote: > >>On Thu, Dec 21, 2017 at 06:52:31PM +, Ghorai, Sukumar wrote: > >> Bug: platform can't wake using LE mouse/ keyboatd or any other LE I/O > >> device connected. > > > >Could you ever? If not, that looks like a feature request

Re: [PATCH 4.4 009/115] Bluetooth: btusb: driver to enable the usb-wakeup feature

On Thu, Dec 21, 2017 at 07:05:03PM +, Ghorai, Sukumar wrote: > >>On Thu, Dec 21, 2017 at 06:52:31PM +, Ghorai, Sukumar wrote: > >> Bug: platform can't wake using LE mouse/ keyboatd or any other LE I/O > >> device connected. > > > >Could you ever? If not, that looks like a feature request

Re: [PATCH 4.4 009/115] Bluetooth: btusb: driver to enable the usb-wakeup feature

On Thu, Dec 21, 2017 at 06:52:31PM +, Ghorai, Sukumar wrote: > Bug: platform can't wake using LE mouse/ keyboatd or any other LE I/O device > connected. Could you ever? If not, that looks like a feature request to me... Brian

Re: [PATCH 4.4 009/115] Bluetooth: btusb: driver to enable the usb-wakeup feature

On Thu, Dec 21, 2017 at 06:52:31PM +, Ghorai, Sukumar wrote: > Bug: platform can't wake using LE mouse/ keyboatd or any other LE I/O device > connected. Could you ever? If not, that looks like a feature request to me... Brian

Re: [PATCH 1/2] Revert "Bluetooth: btusb: fix QCA Rome suspend/resume"

On Thu, Dec 21, 2017 at 3:43 AM, Daniel Drake <dr...@endlessm.com> wrote: > On Wed, Dec 20, 2017 at 6:53 PM, Brian Norris <briannor...@chromium.org> > wrote: >> >> On Wed, Dec 20, 2017 at 07:00:07PM +0800, Kai-Heng Feng wrote: >> > This commit causes a reg

Re: [PATCH 1/2] Revert "Bluetooth: btusb: fix QCA Rome suspend/resume"

On Thu, Dec 21, 2017 at 3:43 AM, Daniel Drake wrote: > On Wed, Dec 20, 2017 at 6:53 PM, Brian Norris > wrote: >> >> On Wed, Dec 20, 2017 at 07:00:07PM +0800, Kai-Heng Feng wrote: >> > This commit causes a regression on some QCA ROME chips. The USB device >&

Re: [PATCH 4.4 009/115] Bluetooth: btusb: driver to enable the usb-wakeup feature

On Thu, Dec 21, 2017 at 12:30 AM, gre...@linuxfoundation.org wrote: > As Linus's tree is also broken, being bug-compatible here is good, > right? I can just apply the revert/fix patch when it lands in that > tree, and all will be ok. > > Or is Linus's tree not broken

Re: [PATCH 4.4 009/115] Bluetooth: btusb: driver to enable the usb-wakeup feature

On Thu, Dec 21, 2017 at 12:30 AM, gre...@linuxfoundation.org wrote: > As Linus's tree is also broken, being bug-compatible here is good, > right? I can just apply the revert/fix patch when it lands in that > tree, and all will be ok. > > Or is Linus's tree not broken now? Sorry, this whole

Re: [PATCH 4.4 009/115] Bluetooth: btusb: driver to enable the usb-wakeup feature

+ Kai One more thing: On Wed, Dec 20, 2017 at 11:51:14AM -0800, Brian Norris wrote: > Hi Greg, > > On Mon, Dec 18, 2017 at 04:47:58PM +0100, Greg Kroah-Hartman wrote: > > 4.4-stable review patch. If anyone has any objections, please let me know. > > I'm sorry, b

Re: [PATCH 4.4 009/115] Bluetooth: btusb: driver to enable the usb-wakeup feature

+ Kai One more thing: On Wed, Dec 20, 2017 at 11:51:14AM -0800, Brian Norris wrote: > Hi Greg, > > On Mon, Dec 18, 2017 at 04:47:58PM +0100, Greg Kroah-Hartman wrote: > > 4.4-stable review patch. If anyone has any objections, please let me know. > > I'm sorry, b

Re: [PATCH 4.4 009/115] Bluetooth: btusb: driver to enable the usb-wakeup feature

Hi Greg, On Mon, Dec 18, 2017 at 04:47:58PM +0100, Greg Kroah-Hartman wrote: > 4.4-stable review patch. If anyone has any objections, please let me know. I'm sorry, but I already objected to this one during the discussion here: https://patchwork.kernel.org/patch/10065483/ [PATCH 4.13 03/28]

Re: [PATCH 4.4 009/115] Bluetooth: btusb: driver to enable the usb-wakeup feature

Hi Greg, On Mon, Dec 18, 2017 at 04:47:58PM +0100, Greg Kroah-Hartman wrote: > 4.4-stable review patch. If anyone has any objections, please let me know. I'm sorry, but I already objected to this one during the discussion here: https://patchwork.kernel.org/patch/10065483/ [PATCH 4.13 03/28]

Re: [PATCH] MAINTAINERS: Move all MTD related branches to a single repo

qualify as "active" these days, but anyway... > patch to the mtd/next branch and ask Stephen to pull next branches from > their new locations. > > In the meantime, we should try to keep both l2-mtd and linux-mtd synced > (that means pushing the xxx/next branches on both l2-

Re: [PATCH] MAINTAINERS: Move all MTD related branches to a single repo

qualify as "active" these days, but anyway... > patch to the mtd/next branch and ask Stephen to pull next branches from > their new locations. > > In the meantime, we should try to keep both l2-mtd and linux-mtd synced > (that means pushing the xxx/next branches on both l2-

Re: [PATCH 1/2] Revert "Bluetooth: btusb: fix QCA Rome suspend/resume"

rks.c. > > Cc: sta...@vger.kernel.org > Cc: Leif Liddy <leif.li...@gmail.com> > Cc: Matthias Kaehlcke <m...@chromium.org> > Cc: Brian Norris <briannor...@chromium.org> > Cc: Daniel Drake <dr...@endlessm.com> > Signed-off-by: Kai-Heng Feng <kai.heng.

Re: [PATCH 1/2] Revert "Bluetooth: btusb: fix QCA Rome suspend/resume"

rks.c. > > Cc: sta...@vger.kernel.org > Cc: Leif Liddy > Cc: Matthias Kaehlcke > Cc: Brian Norris > Cc: Daniel Drake > Signed-off-by: Kai-Heng Feng Looks good to me. Definitely a regression and we need to clear that up in mainline and stable before reintroducing the i

Re: [PATCH 4.13 03/28] Bluetooth: btusb: fix QCA Rome suspend/resume

Hi Kai, On Tue, Dec 19, 2017 at 12:28:17PM +0800, Kai Heng Feng wrote: > > On 19 Dec 2017, at 2:13 AM, Brian Norris <briannor...@chromium.org> wrote: > > On Mon, Dec 18, 2017 at 12:43:48PM +0100, Greg Kroah-Hartman wrote: > >> On Fri, Dec 15, 2017 at 07:05:39PM -08

Re: [PATCH 4.13 03/28] Bluetooth: btusb: fix QCA Rome suspend/resume

Hi Kai, On Tue, Dec 19, 2017 at 12:28:17PM +0800, Kai Heng Feng wrote: > > On 19 Dec 2017, at 2:13 AM, Brian Norris wrote: > > On Mon, Dec 18, 2017 at 12:43:48PM +0100, Greg Kroah-Hartman wrote: > >> On Fri, Dec 15, 2017 at 07:05:39PM -0800, Matthias Kaehlcke wrote: > >

Re: [PATCH for-4.15] wireless: create, don't append, to shipped-certs.c

On Tue, Dec 19, 2017 at 09:11:30PM +0100, Johannes Berg wrote: > I'm not really sure what that problem was - I think a combination of > missing clean-files and this perhaps? Anyway, I applied another fix for > this today, and it's on the way to Linus's tree, along with the missing > clean-files

Re: [PATCH for-4.15] wireless: create, don't append, to shipped-certs.c

On Tue, Dec 19, 2017 at 09:11:30PM +0100, Johannes Berg wrote: > I'm not really sure what that problem was - I think a combination of > missing clean-files and this perhaps? Anyway, I applied another fix for > this today, and it's on the way to Linus's tree, along with the missing > clean-files

[PATCH for-4.15] wireless: create, don't append, to shipped-certs.c

revisions). I don't see why this rule should be an append; we're writing the file all in one go. Fixes: 90a53e4432b1 ("cfg80211: implement regdb signature checking") Signed-off-by: Brian Norris <briannor...@chromium.org> --- This is an error introduced in 4.15-rc1. I've s

[PATCH for-4.15] wireless: create, don't append, to shipped-certs.c

revisions). I don't see why this rule should be an append; we're writing the file all in one go. Fixes: 90a53e4432b1 ("cfg80211: implement regdb signature checking") Signed-off-by: Brian Norris --- This is an error introduced in 4.15-rc1. I've seen other errors reported by Paul and Da

Re: [PATCH for-4.15] ASoC: rt5514: don't assume rt5514 component was "attached"

On Tue, Dec 19, 2017 at 10:58:18AM +, Mark Brown wrote: > It's been applied as a fix for some time. Indeed it has. Sorry for missing that. I look forward to seeing it in a release candidate, so my system will again work on mainline :) Brian

Re: [PATCH for-4.15] ASoC: rt5514: don't assume rt5514 component was "attached"

On Tue, Dec 19, 2017 at 10:58:18AM +, Mark Brown wrote: > It's been applied as a fix for some time. Indeed it has. Sorry for missing that. I look forward to seeing it in a release candidate, so my system will again work on mainline :) Brian

Re: [RFC PATCH v2 1/3] PCI: rockchip: Add support for pcie wake irq

Hi Jeffy, Tony, On Wed, Aug 23, 2017 at 09:32:39AM +0800, Jeffy Chen wrote: > Hi Tony, > > On 08/23/2017 01:26 AM, Tony Lindgren wrote: > >OK, let's fix any wakeriq ordering issues to make it more > >usable. Sounds like in your case the wakeirq needs to be enabled > >late and disabled early,

Re: [RFC PATCH v2 1/3] PCI: rockchip: Add support for pcie wake irq

Hi Jeffy, Tony, On Wed, Aug 23, 2017 at 09:32:39AM +0800, Jeffy Chen wrote: > Hi Tony, > > On 08/23/2017 01:26 AM, Tony Lindgren wrote: > >OK, let's fix any wakeriq ordering issues to make it more > >usable. Sounds like in your case the wakeirq needs to be enabled > >late and disabled early,

[PATCH TRIVIAL] PM / wakeup: only recommend "call"ing device_init_wakeup() once

I'll admit admit it: I've written bad driver code that tries to configure a device's wake IRQ without having called device_init_wakeup() first. But do you really have to ask ask me twice? Signed-off-by: Brian Norris <briannor...@chromium.org> --- drivers/base/power/wakeup.c | 2 +-

[PATCH TRIVIAL] PM / wakeup: only recommend "call"ing device_init_wakeup() once

I'll admit admit it: I've written bad driver code that tries to configure a device's wake IRQ without having called device_init_wakeup() first. But do you really have to ask ask me twice? Signed-off-by: Brian Norris --- drivers/base/power/wakeup.c | 2 +- 1 file changed, 1 insertion(+), 1

Re: [PATCH 4.13 03/28] Bluetooth: btusb: fix QCA Rome suspend/resume

Hi Greg, On Mon, Dec 18, 2017 at 12:43:48PM +0100, Greg Kroah-Hartman wrote: > On Fri, Dec 15, 2017 at 07:05:39PM -0800, Matthias Kaehlcke wrote: > > We identified the above patch as the culprit, in combination with USB > > autosuspend being enabled for the Bluetooth controller. > > > > We found

Re: [PATCH 4.13 03/28] Bluetooth: btusb: fix QCA Rome suspend/resume

Hi Greg, On Mon, Dec 18, 2017 at 12:43:48PM +0100, Greg Kroah-Hartman wrote: > On Fri, Dec 15, 2017 at 07:05:39PM -0800, Matthias Kaehlcke wrote: > > We identified the above patch as the culprit, in combination with USB > > autosuspend being enabled for the Bluetooth controller. > > > > We found

Re: [PATCH v4 1/2] mfd: cros_ec: Introduce RTC commands and events definitions.

On Sat, Dec 16, 2017 at 08:36:23AM +0100, Enric Balletbo Serra wrote: >Guess you missed the discussion in the cover letter of this patchset ;) >These patches has been accepted and merged soon for 4.16. Alexandre >will do it. I wasn't copied on either the patches or the cover letter; I

Re: [PATCH v4 1/2] mfd: cros_ec: Introduce RTC commands and events definitions.

On Sat, Dec 16, 2017 at 08:36:23AM +0100, Enric Balletbo Serra wrote: >Guess you missed the discussion in the cover letter of this patchset ;) >These patches has been accepted and merged soon for 4.16. Alexandre >will do it. I wasn't copied on either the patches or the cover letter; I

Re: [PATCH for-4.15] ASoC: rt5514: don't assume rt5514 component was "attached"

Hi! (By the way, your mail is HTML and likely will get rejected by many mailing lists and/or people reading these mailing lists.) On Mon, Dec 18, 2017 at 12:23:18PM +0800, Cheng-yi Chiang wrote: >Hi Brian, > Oder has posted the same fix : [1]https://patchwork.kernel.org/ >

Re: [PATCH for-4.15] ASoC: rt5514: don't assume rt5514 component was "attached"

Hi! (By the way, your mail is HTML and likely will get rejected by many mailing lists and/or people reading these mailing lists.) On Mon, Dec 18, 2017 at 12:23:18PM +0800, Cheng-yi Chiang wrote: >Hi Brian, > Oder has posted the same fix : [1]https://patchwork.kernel.org/ >

Re: [PATCH v4 2/2] rtc: cros-ec: add cros-ec-rtc driver.

+ RTC maintainers On Fri, Dec 15, 2017 at 08:57:50PM -0800, Brian Norris wrote: > On Fri, Nov 10, 2017 at 10:55:53PM +0100, Enric Balletbo i Serra wrote: > > From: Stephen Barber <smbar...@chromium.org> > > > > On platforms with a Chrome OS EC, the EC can functi

Re: [PATCH v4 2/2] rtc: cros-ec: add cros-ec-rtc driver.

+ RTC maintainers On Fri, Dec 15, 2017 at 08:57:50PM -0800, Brian Norris wrote: > On Fri, Nov 10, 2017 at 10:55:53PM +0100, Enric Balletbo i Serra wrote: > > From: Stephen Barber > > > > On platforms with a Chrome OS EC, the EC can function as a simple RTC. &

Re: [PATCH v4 2/2] rtc: cros-ec: add cros-ec-rtc driver.

ctually create the device, but it's a good start, and I don't see any problems with it. Any reason this isn't merged? Are the RTC maintainers intendending to merge this, or should Lee (for the MFD header)? I thought normally Lee deferred to other subsystem maintainers when the only "MFD" stuff wa

Re: [PATCH v4 2/2] rtc: cros-ec: add cros-ec-rtc driver.

s, or should Lee (for the MFD header)? I thought normally Lee deferred to other subsystem maintainers when the only "MFD" stuff was a simple header change (such as in patch 1). Anyway, FWIW: Reviewed-by: Brian Norris Tested-by: Brian Norris

Re: [PATCH v4 1/2] mfd: cros_ec: Introduce RTC commands and events definitions.

y: Stephen Barber <smbar...@chromium.org> > Signed-off-by: Enric Balletbo i Serra <enric.balle...@collabora.com> > Acked-by: Lee Jones <lee.jo...@linaro.org> > Acked-by: Benson Leung <ble...@chromium.org> Reviewed-by: Brian Norris <briannor...@chromium.org> I guess

Re: [PATCH v4 1/2] mfd: cros_ec: Introduce RTC commands and events definitions.

nric Balletbo i Serra > Acked-by: Lee Jones > Acked-by: Benson Leung Reviewed-by: Brian Norris I guess this is waiting to get merged by an RTC maintainer, since it's a dependency for the RTC driver in patch 2? Alessandro or Alexandre, any thoughts? Brian > --- > include

[PATCH for-4.15] ASoC: rt5514-spi: only enable wakeup when fully initialized

s). Fixes: 58f1c07d23cd ("ASoC: rt5514: Voice wakeup support.") Signed-off-by: Brian Norris <briannor...@chromium.org> --- The patch that introduced the wakeup was in 4.15-rc1. I think this qualifies as a bugfix, and should probably go into 4.15. Other relevant patches that a

[PATCH for-4.15] ASoC: rt5514-spi: only enable wakeup when fully initialized

s). Fixes: 58f1c07d23cd ("ASoC: rt5514: Voice wakeup support.") Signed-off-by: Brian Norris --- The patch that introduced the wakeup was in 4.15-rc1. I think this qualifies as a bugfix, and should probably go into 4.15. Other relevant patches that are useful, and fix similar (or the

Re: [PATCH] ASoC: rockchip: Use dummy_dai for rt5514 dsp dailink

assumes that the DAI link was correctly configured (that's the subject of another patch I sent [1] I believe this was working fine on 4.14? At least, I know (b) didn't happen, and I'm not sure about (a). (c) is a new issue in 4.15-rc1. Anyway, that's all to say: Tested-by: Brian Norris &l

Re: [PATCH] ASoC: rockchip: Use dummy_dai for rt5514 dsp dailink

subject of another patch I sent [1] I believe this was working fine on 4.14? At least, I know (b) didn't happen, and I'm not sure about (a). (c) is a new issue in 4.15-rc1. Anyway, that's all to say: Tested-by: Brian Norris on the "kevin" Chromebook (Samsung Chromebook Plus). I

Re: [PATCH for-4.15] ASoC: rt5514: don't assume rt5514 component was "attached"

+ others On Fri, Dec 15, 2017 at 05:12:30PM -0800, Brian Norris wrote: > I've found that on Google's "Kevin" Chromebook, the rt5514 codec might > not be set up completely, yet its device is still present, and therefore > its PM suspend/resume is called. This hits a NULL pointer

Re: [PATCH for-4.15] ASoC: rt5514: don't assume rt5514 component was "attached"

+ others On Fri, Dec 15, 2017 at 05:12:30PM -0800, Brian Norris wrote: > I've found that on Google's "Kevin" Chromebook, the rt5514 codec might > not be set up completely, yet its device is still present, and therefore > its PM suspend/resume is called. This hits a NULL pointer

[PATCH for-4.15] ASoC: rt5514: don't assume rt5514 component was "attached"

ashes seen when trying to resume my system. Fixes: e9c50aa6bd39 ("ASoC: rt5514-spi: check irq status to schedule data copy in resume function") Signed-off-by: Brian Norris <briannor...@chromium.org> --- This is a v4.15-rc1 regression sound/soc/codecs/rt5514-spi.c | 2 +- 1 file

[PATCH for-4.15] ASoC: rt5514: don't assume rt5514 component was "attached"

ashes seen when trying to resume my system. Fixes: e9c50aa6bd39 ("ASoC: rt5514-spi: check irq status to schedule data copy in resume function") Signed-off-by: Brian Norris --- This is a v4.15-rc1 regression sound/soc/codecs/rt5514-spi.c | 2 +- 1 file changed, 1 insertion(+), 1 del

Re: [RESEND PATCH v3 1/3] drm/panel: refactor INNOLUX P079ZCA panel driver

Hi HL, On Mon, Dec 04, 2017 at 03:17:48PM +0800, Lin Huang wrote: > Refactor Innolux P079ZCA panel driver, let it support > multi panel. > > Signed-off-by: Lin Huang > --- > Changes in v2: > - Change regulator property name to meet the panel datasheet > Changes in v3: > -

Re: [RESEND PATCH v3 1/3] drm/panel: refactor INNOLUX P079ZCA panel driver

Hi HL, On Mon, Dec 04, 2017 at 03:17:48PM +0800, Lin Huang wrote: > Refactor Innolux P079ZCA panel driver, let it support > multi panel. > > Signed-off-by: Lin Huang > --- > Changes in v2: > - Change regulator property name to meet the panel datasheet > Changes in v3: > - this patch only

[PATCH] pinctrl: rockchip: enable clock when reading pin direction register

get the right results! [1] Sometimes, because many systems have 1 or mor interrupt requested on each GPIO bank, so they always leave their clock on. [2] Incorrect, meaning the register returns 0, and so we interpret that as "input". Signed-off-by: Brian Norris <briannor...@chromium.org> -

[PATCH] pinctrl: rockchip: enable clock when reading pin direction register

get the right results! [1] Sometimes, because many systems have 1 or mor interrupt requested on each GPIO bank, so they always leave their clock on. [2] Incorrect, meaning the register returns 0, and so we interpret that as "input". Signed-off-by: Brian Norris --- drivers/pinctrl/pinctrl-r

Re: [PATCH v6 1/3] drm/bridge/synopsys: dsi: stop clobbering drvdata

On Thu, Dec 07, 2017 at 11:41:17AM +, Philippe CORNU wrote: > platform_set_drvdata() is still missing in your version. Ugh...indeed. > On 12/06/2017 10:39 PM, Brian Norris wrote: > > On Wed, Dec 06, 2017 at 05:08:19PM +0800, Nickey Yang wrote: > >> From: B

Re: [PATCH v6 1/3] drm/bridge/synopsys: dsi: stop clobbering drvdata

On Thu, Dec 07, 2017 at 11:41:17AM +, Philippe CORNU wrote: > platform_set_drvdata() is still missing in your version. Ugh...indeed. > On 12/06/2017 10:39 PM, Brian Norris wrote: > > On Wed, Dec 06, 2017 at 05:08:19PM +0800, Nickey Yang wrote: > >> From: Brian Nor

Re: [RFC PATCH v10 6/7] PCI / PM: Move acpi wakeup code to pci core

On Wed, Dec 06, 2017 at 04:17:54PM -0800, Tony Lindgren wrote: > * Brian Norris <briannor...@chromium.org> [171206 19:36]: > > By the way, it seems pretty ambiguous how we want to handle things like > > (a) multiple devices sharing the same WAKE# > > (b) system

Re: [RFC PATCH v10 6/7] PCI / PM: Move acpi wakeup code to pci core

On Wed, Dec 06, 2017 at 04:17:54PM -0800, Tony Lindgren wrote: > * Brian Norris [171206 19:36]: > > By the way, it seems pretty ambiguous how we want to handle things like > > (a) multiple devices sharing the same WAKE# > > (b) systems where a slot is swappable > > &g

Re: [PATCH v6 3/3] drm/rockchip: Add ROCKCHIP DW MIPI DSI controller driver

bridge. > > Signed-off-by: Nickey Yang <nickey.y...@rock-chips.com> > Signed-off-by: Brian Norris <briannor...@chromium.org> > Reviewed-by: Brian Norris <briannor...@chromium.org> > Reviewed-by: Sean Paul <seanp...@chromium.org> > --- > change: > > v

Re: [PATCH v6 3/3] drm/rockchip: Add ROCKCHIP DW MIPI DSI controller driver

bridge. > > Signed-off-by: Nickey Yang > Signed-off-by: Brian Norris > Reviewed-by: Brian Norris > Reviewed-by: Sean Paul > --- > change: > > v2: >add err_pllref, remove unnecessary encoder.enable & disable >correct spelling

Re: [PATCH v6 1/3] drm/bridge/synopsys: dsi: stop clobbering drvdata

On Wed, Dec 06, 2017 at 05:08:19PM +0800, Nickey Yang wrote: > From: Brian Norris <briannor...@chromium.org> > > Bridge drivers/helpers shouldn't be clobbering the drvdata, since a > parent driver might need to own this. Instead, let's return our > 'dw_mipi_dsi' object

Re: [PATCH v6 1/3] drm/bridge/synopsys: dsi: stop clobbering drvdata

On Wed, Dec 06, 2017 at 05:08:19PM +0800, Nickey Yang wrote: > From: Brian Norris > > Bridge drivers/helpers shouldn't be clobbering the drvdata, since a > parent driver might need to own this. Instead, let's return our > 'dw_mipi_dsi' object and have callers pass that back to

Re: [RFC PATCH v10 6/7] PCI / PM: Move acpi wakeup code to pci core

, but perhaps you or someone else on copy can humor me?) I'm also not sure I agree with all of your suggestions, though maybe something "similar" could be OK. On Wed, Nov 22, 2017 at 01:26:02AM +0100, Rafael J. Wysocki wrote: > On Tuesday, November 14, 2017 3:51:11 AM CET Brian

Re: [RFC PATCH v10 6/7] PCI / PM: Move acpi wakeup code to pci core

, but perhaps you or someone else on copy can humor me?) I'm also not sure I agree with all of your suggestions, though maybe something "similar" could be OK. On Wed, Nov 22, 2017 at 01:26:02AM +0100, Rafael J. Wysocki wrote: > On Tuesday, November 14, 2017 3:51:11 AM CET Brian

Re: [PATCH 3/3] arm64: dts: rockchip: add extcon nodes and enable tcphy.

"okay"; > + extcon = <_extcon1>; > }; > > _dwc3_1 { Seems OK. Also, IIUC, I think if we ever want to support dual-role/OTG, we need an extcon reference in the USB2/OTG PHY that serves these ports too. i.e., u2phy0 and u2phy1? Notably, the PHY driver supports the extcon properties, but it's not documented in Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt yet (we should probably get that fixed). So, anyway, maybe the above isn't a blocker for this patch. Just noticed it while reading. Assuming the driver stuff falls into place: Reviewed-by: Brian Norris <briannor...@chromium.org>

Re: [PATCH 3/3] arm64: dts: rockchip: add extcon nodes and enable tcphy.

>; > }; > > _dwc3_1 { Seems OK. Also, IIUC, I think if we ever want to support dual-role/OTG, we need an extcon reference in the USB2/OTG PHY that serves these ports too. i.e., u2phy0 and u2phy1? Notably, the PHY driver supports the extcon properties, but it's not documented in Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.txt yet (we should probably get that fixed). So, anyway, maybe the above isn't a blocker for this patch. Just noticed it while reading. Assuming the driver stuff falls into place: Reviewed-by: Brian Norris

Re: [PATCH v4 1/3] drm/bridge/synopsys: dsi: stop clobbering drvdata

Hi Nickey, On Tue, Dec 05, 2017 at 05:14:11PM +0800, Nickey Yang wrote: > On 2017年12月01日 18:07, Philippe CORNU wrote: > >On 12/01/2017 10:11 AM, Nickey Yang wrote: > >>On 2017年12月01日 16:32, Philippe CORNU wrote: > >>>I am sorry to say that but you can not add my "Acked-by" to this patch >

Re: [PATCH v4 1/3] drm/bridge/synopsys: dsi: stop clobbering drvdata

Hi Nickey, On Tue, Dec 05, 2017 at 05:14:11PM +0800, Nickey Yang wrote: > On 2017年12月01日 18:07, Philippe CORNU wrote: > >On 12/01/2017 10:11 AM, Nickey Yang wrote: > >>On 2017年12月01日 16:32, Philippe CORNU wrote: > >>>I am sorry to say that but you can not add my "Acked-by" to this patch >

Re: [PATCH v3 5/6] dt-bindings: add the rockchip, dual-channel for dw-mipi-dsi

Hi Archit, I'm a relative n00b here, but I'm trying to follow along and I have some questions: On Fri, Dec 01, 2017 at 06:29:04PM +0530, Archit Taneja wrote: > On 11/30/2017 11:02 PM, Nickey Yang wrote: > >I try to follow as you suggested,use > > > >mipi_dsi: mipi@ff96 { > >     ... > >    

Re: [PATCH v3 5/6] dt-bindings: add the rockchip, dual-channel for dw-mipi-dsi

Hi Archit, I'm a relative n00b here, but I'm trying to follow along and I have some questions: On Fri, Dec 01, 2017 at 06:29:04PM +0530, Archit Taneja wrote: > On 11/30/2017 11:02 PM, Nickey Yang wrote: > >I try to follow as you suggested,use > > > >mipi_dsi: mipi@ff96 { > >     ... > >    

Re: [PATCH v4 2/3] dt-bindings: display: rockchip: update DSI controller

ned-off-by: Nickey Yang <nickey.y...@rock-chips.com> Seems OK to me: Reviewed-by: Brian Norris <briannor...@chromium.org> > > --- > Changes in v4: > - keep the -cells properties > > .../display/rockchip/dw_mipi_dsi_rockchip.txt | 23 >

Re: [PATCH v4 2/3] dt-bindings: display: rockchip: update DSI controller

ned-off-by: Nickey Yang Seems OK to me: Reviewed-by: Brian Norris > > --- > Changes in v4: > - keep the -cells properties > > .../display/rockchip/dw_mipi_dsi_rockchip.txt | 23 > -- > 1 file changed, 21 insertions(+), 2 deletions(-) >

Re: [RESENT PATCH] drm/panel: support Innolux P097PFG panel

One more comment: On Thu, Nov 30, 2017 at 02:14:40PM +0800, Lin Huang wrote: > Support Innolux P097PFG 9.7" 1536x2048 TFT LCD panel, > it refactor Innolux P079ZCA panel driver, let it support > multi panel, and add support P097PFG panel in this driver. > > Signed-off-by: Lin Huang

Re: [RESENT PATCH] drm/panel: support Innolux P097PFG panel

One more comment: On Thu, Nov 30, 2017 at 02:14:40PM +0800, Lin Huang wrote: > Support Innolux P097PFG 9.7" 1536x2048 TFT LCD panel, > it refactor Innolux P079ZCA panel driver, let it support > multi panel, and add support P097PFG panel in this driver. > > Signed-off-by: Lin Huang > > --- >

Re: [RESENT PATCH] drm/panel: support Innolux P097PFG panel

+ Derek On Thu, Nov 30, 2017 at 02:14:40PM +0800, Lin Huang wrote: > Support Innolux P097PFG 9.7" 1536x2048 TFT LCD panel, > it refactor Innolux P079ZCA panel driver, let it support > multi panel, and add support P097PFG panel in this driver. > > Signed-off-by: Lin Huang >

Re: [RESENT PATCH] drm/panel: support Innolux P097PFG panel

+ Derek On Thu, Nov 30, 2017 at 02:14:40PM +0800, Lin Huang wrote: > Support Innolux P097PFG 9.7" 1536x2048 TFT LCD panel, > it refactor Innolux P079ZCA panel driver, let it support > multi panel, and add support P097PFG panel in this driver. > > Signed-off-by: Lin Huang > > --- >

Re: [PATCH v3 3/5] dt-bindings: display: rockchip: update DSI controller

On Tue, Nov 28, 2017 at 07:20:04PM +0800, Nickey Yang wrote: > This patch update documentation of device tree bindings for the rockchip > DSI controller based on the Synopsys DesignWare MIPI DSI host controller. It might help to describe why you're doing this. Just saying "update" is pretty

Re: [PATCH v3 3/5] dt-bindings: display: rockchip: update DSI controller

On Tue, Nov 28, 2017 at 07:20:04PM +0800, Nickey Yang wrote: > This patch update documentation of device tree bindings for the rockchip > DSI controller based on the Synopsys DesignWare MIPI DSI host controller. It might help to describe why you're doing this. Just saying "update" is pretty

[PATCH] arm64: dts: rockchip: add mipi_dsi1 support for rk3399

From: Nickey Yang <nickey.y...@rock-chips.com> This patch adds the information for the secondary MIPI DSI controller, e.g., interrupts, grf, clocks, ports and so on. Mirrors the existing definition for dsi0. Signed-off-by: Nickey Yang <nickey.y...@rock-chips.com> Signed-off-by:

[PATCH] arm64: dts: rockchip: add mipi_dsi1 support for rk3399

From: Nickey Yang This patch adds the information for the secondary MIPI DSI controller, e.g., interrupts, grf, clocks, ports and so on. Mirrors the existing definition for dsi0. Signed-off-by: Nickey Yang Signed-off-by: Brian Norris --- arch/arm64/boot/dts/rockchip/rk3399.dtsi | 45

Re: [PATCH] arm64: dts: rockchip: add rk3399 DSI0 reset

On Wed, Nov 29, 2017 at 05:07:27PM -0800, Brian Norris wrote: Sorry, I got the wrong $subject, will resend :(

Re: [PATCH] arm64: dts: rockchip: add rk3399 DSI0 reset

On Wed, Nov 29, 2017 at 05:07:27PM -0800, Brian Norris wrote: Sorry, I got the wrong $subject, will resend :(

[PATCH] arm64: dts: rockchip: add rk3399 DSI0 reset

From: Nickey Yang <nickey.y...@rock-chips.com> This patch adds the information for the secondary MIPI DSI controller, e.g., interrupts, grf, clocks, ports and so on. Mirrors the existing definition for dsi0. Signed-off-by: Nickey Yang <nickey.y...@rock-chips.com> Signed-off-by:

[PATCH] arm64: dts: rockchip: add rk3399 DSI0 reset

From: Nickey Yang This patch adds the information for the secondary MIPI DSI controller, e.g., interrupts, grf, clocks, ports and so on. Mirrors the existing definition for dsi0. Signed-off-by: Nickey Yang Signed-off-by: Brian Norris --- arch/arm64/boot/dts/rockchip/rk3399.dtsi | 45

[PATCH] arm64: dts: rockchip: add rk3399 DSI0 reset

We've documented this one already, but we didn't add it to the DTSI yet. Suggested-by: Nickey Yang <nickey.y...@rock-chips.com> Signed-off-by: Brian Norris <briannor...@chromium.org> --- arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git

[PATCH] arm64: dts: rockchip: add rk3399 DSI0 reset

We've documented this one already, but we didn't add it to the DTSI yet. Suggested-by: Nickey Yang Signed-off-by: Brian Norris --- arch/arm64/boot/dts/rockchip/rk3399.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts

[PATCH v4] arm64: dts: rockchip: update mipi cells for RK3399

e from the rest of the series, since this is mostly independent of the driver refactoring Signed-off-by: Nickey Yang <nickey.y...@rock-chips.com> Signed-off-by: Brian Norris <briannor...@chromium.org> --- arch/arm64/boot/dts/rockchip/rk3399.dtsi | 6 +- 1 file changed, 5 inserti

[PATCH v4] arm64: dts: rockchip: update mipi cells for RK3399

this is mostly independent of the driver refactoring Signed-off-by: Nickey Yang Signed-off-by: Brian Norris --- arch/arm64/boot/dts/rockchip/rk3399.dtsi | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3399.dtsi b/arch/arm64/boot/dts

Re: [PATCH v3 5/5] arm64: dts: rockchip: update mipi node for RK3399

+ Doug, since he was asking these things elsewhere On Tue, Nov 28, 2017 at 07:20:06PM +0800, Nickey Yang wrote: > This patch update mipi node for RK3399 DSI controller > based on the Synopsys DesignWare MIPI DSI host controller. > > Signed-off-by: Nickey Yang > --- >

Re: [PATCH v3 5/5] arm64: dts: rockchip: update mipi node for RK3399

+ Doug, since he was asking these things elsewhere On Tue, Nov 28, 2017 at 07:20:06PM +0800, Nickey Yang wrote: > This patch update mipi node for RK3399 DSI controller > based on the Synopsys DesignWare MIPI DSI host controller. > > Signed-off-by: Nickey Yang > --- >

Re: [PATCH v3 4/5] drm/rockchip: Add ROCKCHIP DW MIPI DSI controller driver

On Tue, Nov 28, 2017 at 6:02 PM, Sean Paul <seanp...@chromium.org> wrote: > On Tue, Nov 28, 2017 at 02:55:41PM -0800, Brian Norris wrote: >> On Tue, Nov 28, 2017 at 12:48:43PM -0800, Matthias Kaehlcke wrote: >> > El Tue, Nov 28, 2017 at 07:20:05PM +0800 Nickey Yang

Re: [PATCH v3 4/5] drm/rockchip: Add ROCKCHIP DW MIPI DSI controller driver

On Tue, Nov 28, 2017 at 6:02 PM, Sean Paul wrote: > On Tue, Nov 28, 2017 at 02:55:41PM -0800, Brian Norris wrote: >> On Tue, Nov 28, 2017 at 12:48:43PM -0800, Matthias Kaehlcke wrote: >> > El Tue, Nov 28, 2017 at 07:20:05PM +0800 Nickey Yang ha dit: >> > >> &g

Re: [PATCH v3 4/5] drm/rockchip: Add ROCKCHIP DW MIPI DSI controller driver

+ > > + _fbdiv += _fbdiv % 2; > > + > > + tmp = (u64)_fbdiv * fin; > > + do_div(tmp, _prediv); > > Should we bail out early if min_prediv == 0 due to some bogus > configuration of pllref_clk? > > > + if (tmp < fvco_min || tmp > fvco_max) > > + continue; > > + > > + delta = abs(fout - tmp); > > + if (delta < min_delta) { > > + best_prediv = _prediv; > > + best_fbdiv = _fbdiv; > > + min_delta = delta; > > + best_freq = tmp; > > + } > > + } > > + > > + if (best_freq) { > > + dsi->lane_mbps = DIV_ROUND_UP(best_freq, USEC_PER_SEC); > > + *lane_mbps = dsi->lane_mbps; > > + dsi->input_div = best_prediv; > > + dsi->feedback_div = best_fbdiv; > > + } else { > > + DRM_DEV_ERROR(dsi->dev, "Can not find best_freq for DPHY\n"); > > return -1; Or a real error code would be nicer. -EINVAL? > > + } > > + > > + return 0; > > +} > > + ... Other than these relatively small things, this is looking pretty good to my (not-well-versed-in-drm) eye: Reviewed-by: Brian Norris <briannor...@chromium.org>

Re: [PATCH v3 4/5] drm/rockchip: Add ROCKCHIP DW MIPI DSI controller driver

% 2; > > + > > + tmp = (u64)_fbdiv * fin; > > + do_div(tmp, _prediv); > > Should we bail out early if min_prediv == 0 due to some bogus > configuration of pllref_clk? > > > + if (tmp < fvco_min || tmp > fvco_max) > > + continue; > > + > > + delta = abs(fout - tmp); > > + if (delta < min_delta) { > > + best_prediv = _prediv; > > + best_fbdiv = _fbdiv; > > + min_delta = delta; > > + best_freq = tmp; > > + } > > + } > > + > > + if (best_freq) { > > + dsi->lane_mbps = DIV_ROUND_UP(best_freq, USEC_PER_SEC); > > + *lane_mbps = dsi->lane_mbps; > > + dsi->input_div = best_prediv; > > + dsi->feedback_div = best_fbdiv; > > + } else { > > + DRM_DEV_ERROR(dsi->dev, "Can not find best_freq for DPHY\n"); > > return -1; Or a real error code would be nicer. -EINVAL? > > + } > > + > > + return 0; > > +} > > + ... Other than these relatively small things, this is looking pretty good to my (not-well-versed-in-drm) eye: Reviewed-by: Brian Norris

Re: [PATCH v3 2/5] drm/stm: dsi: Adjust dw_mipi_dsi_probe and remove

> --- > drivers/gpu/drm/stm/dw_mipi_dsi-stm.c | 8 +--- > 1 file changed, 5 insertions(+), 3 deletions(-) So, you've split my patch in 2 and called it your own (see patch 1, which still has the 'From' (i.e., author) line as "Nickey Yang", not "Brian Norris"). You

Re: [PATCH v3 2/5] drm/stm: dsi: Adjust dw_mipi_dsi_probe and remove

m/dw_mipi_dsi-stm.c | 8 +--- > 1 file changed, 5 insertions(+), 3 deletions(-) So, you've split my patch in 2 and called it your own (see patch 1, which still has the 'From' (i.e., author) line as "Nickey Yang", not "Brian Norris"). You need to keep the author accurate. (

Re: [PATCH] drm/bridge/synopsis: stop clobbering drvdata

t need another tag in the subject? e.g., '.../dw-mipi-dsi:'? > On Tuesday, 28 November 2017 03:05:38 EET Brian Norris wrote: > > Bridge drivers/helpers shouldn't be clobbering the drvdata, since a > > parent driver might need to own this. > > By parent driver I assume you mean a glue d

Re: [PATCH] drm/bridge/synopsis: stop clobbering drvdata

t need another tag in the subject? e.g., '.../dw-mipi-dsi:'? > On Tuesday, 28 November 2017 03:05:38 EET Brian Norris wrote: > > Bridge drivers/helpers shouldn't be clobbering the drvdata, since a > > parent driver might need to own this. > > By parent driver I assume you mean a glue d

Re: [PATCH v2 2/3] drm/rockchip: Add ROCKCHIP DW MIPI DSI controller driver

Hi Nickey, Thanks for the quick version 2. You've fixed most of the the problems I pointed out, but you've missed at least one. On Tue, Nov 28, 2017 at 09:55:24AM +0800, Nickey Yang wrote: > Add the ROCKCHIP DSI controller driver that uses the Synopsys DesignWare > MIPI DSI host controller

<    1   2   3   4   5   6   7   8   9   10   >