Hi Marc and Mark,
Mark already noticed this was no longer needed, but I just wanted to
note things for the record, since Marc seemed curious.
On Wed, Jan 24, 2018 at 7:36 AM, Mark Brown wrote:
...
>
> From 509bf3a7d43ab173abc354df2a859229ede043c0 Mon Sep 17 00:00:00 2001
> From: Marc Zyngier
>
Hi Philippe,
On Tue, Jan 23, 2018 at 6:26 AM, Philippe Cornu wrote:
> The dw_mipi_dsi_host_transfer() must return the number of
> bytes transmitted/received on success instead of 0.
I'm a little confused. As of the latest drm-misc-next I'm looking at,
this still has conflicting documentation.
F
Hi Philippe,
I see you sent this out already today, while I only just responded
(late) to your questions about it... oh well :)
On Tue, Jan 23, 2018 at 6:26 AM, Philippe Cornu wrote:
> The DCS/GENERIC DSI read feature is not yet implemented so it
> is important to warn the host_transfer() caller
Hi Philippe,
On Thu, Jan 18, 2018 at 11:40:48AM +, Philippe CORNU wrote:
> On 01/11/2018 12:16 PM, Philippe CORNU wrote:
> > To be honest, I do not really like the memcpy here too and I agree with
> > you regarding the BE issue.
> >
> > My first "stm" driver (ie. before using this "freescale
Hi,
Philippe asked me to review the last version. I'm not sure I have a lot
to contribute. Maybe Rockchip folks who wrote this stuff in the first
place might. I've CC'd some.
On Tue, Jan 23, 2018 at 06:08:06PM +0100, Philippe Cornu wrote:
> The pixel clock is optional. When available, it offers a
can't see any in this patch.
>
> >
> > Change-Id: I1fb2117296373fa67397fdd4a8960077b241462e
>
> It's been mentioned somewhere else in the thread: these tags have no
> purpose in the kernel. Please sanitise your patches before posting them.
>
> > Signed-off-by: Dere
On Thu, Jan 18, 2018 at 06:20:09PM +0100, Enric Balletbo Serra wrote:
> As Brian said commit 06c47e6286d5 'usb: dwc3: of-simple: Add support
> to get resets for the device' introduced the support to get the resets
> from dwc3-of-simple and the queued commit 'b7e63d95c14d arm64: dts:
> rockchip: add
On Tue, Jan 16, 2018 at 10:24:59AM +0200, Claudiu Beznea wrote:
> Please explain me further. From this I understand, as a general rule,
> that the device tree binaries from, e.g. 3 years ago, should be
> compatible with, e.g. the current version of kernel?
Yes.
https://www.kernel.org/doc/Document
On Wed, Jan 17, 2018 at 10:29:53AM +0200, Claudiu Beznea wrote:
> With these changes, if pwm-cells=1 then only PWM-channel will be parsed,
I'm not sure if I'm understanding you correctly but...no. If cells is 1,
then your driver change just causes us not to parse correctly, and
everything fails.
+ Enric
On Fri, Jan 12, 2018 at 06:08:22PM +0800, William Wu wrote:
> This patch adds USB3 OTG reset property for rk3399 Type-C PHY
> to hold the USB3 controller in reset state.
>
> Signed-off-by: William Wu
> ---
I was going back and forth on this, since at one point this binding was
merged bu
ntroller before initializing Type-C PHY on rk3399
or at least mentioned there, because the series there doesn't quite
right otherwise, no?
Anyway, I think this patch looks OK. I don't immediately see good
reasons for delaying the PHY init until later, and I do see reasons why
it could be usefu
In this function, we init the USB2 and USB3 PHYs, but if soft reset
times out, we don't unwind this.
Noticed by inspection.
Signed-off-by: Brian Norris
---
drivers/usb/dwc3/core.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
Hi all,
I believe Philippe's comments about return values have been addressed
separately, and this patch was applied to drm-misc-next. But I have one
additional thought below.
On Tue, Jan 09, 2018 at 12:32:47PM -0800, Brian Norris wrote:
> This takes care of 2 TODOs in this driver, by u
On Tue, Jan 16, 2018 at 12:22:52PM +0530, Archit Taneja wrote:
> On 01/10/2018 08:03 PM, Andrzej Hajda wrote:
> >On 09.01.2018 21:32, Brian Norris wrote:
> >>@@ -386,9 +386,9 @@ static int dw_mipi_dsi_write(struct dw_mipi_dsi *dsi,
> >>}
> >>}
&
On Fri, Jan 12, 2018 at 01:24:15PM -0800, Derek Basehore wrote:
> If cpu_cluster_pm_enter() fails, cpu_pm_exit() should be called. This
> will put the CPU in the correct state to resume from the failure.
>
> Change-Id: I4e499d686ea6046103be355d3a92bb0d51525f53
If you ran checkpatch.pl, it would w
to happen, we can always try again later.
Fixes: b014e96d1abb ("PCI: Protect pci_error_handlers->reset_notify() usage
with device_lock()")
Cc:
Cc: Xinming Hu
Signed-off-by: Brian Norris
---
drivers/net/wireless/marvell/mwifiex/pcie.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-
ie_card_reset_work().
The proper thing to do is just to fix the deadlock. Patch for this will
come separately.
Cc: Signed-off-by: Xinming Hu
Signed-off-by: Brian Norris
---
drivers/net/wireless/marvell/mwifiex/pcie.c | 2 --
drivers/net/wireless/marvell/mwifiex/sdio.c | 2 --
2 files chan
in the format described
> in pwm documentation).
>
> Cc: Thierry Reding
> Cc: Mike Dunn
> Cc: Brian Norris
> Cc: Alexander Shiyan
> Signed-off-by: Claudiu Beznea
> ---
>
> This patch (and the next 7) could be applied independetly by this series, if
> any,
On Fri, Jan 12, 2018 at 04:22:50PM +0200, Claudiu Beznea wrote:
> pwm-cells should be at least 2 to provide channel number and period value.
Nacked-by: Brian Norris
We don't control the period from the kernel; only the duty cycle. (Now,
that's perhaps not a wise firmware interfac
On Wed, Jan 10, 2018 at 12:31:31PM +0100, Marc Dietrich wrote:
> Hi,
>
> Am Samstag, 6. Januar 2018, 01:47:56 CET schrieb Brian Norris:
> > This was used out-of-tree as a hack for resolving issues where some
> > systems expect the backlight to turn on automatically at b
in
> Reviewed-by: Brian Norris
> Tested-by: Caesar Wang
> Tested-by: Ziyuan Xu
> ---
>
> Changes in v2:
> - propagate the error and print it
> - avoid using busy wait
>
> drivers/phy/rockchip/phy-rockchip-emmc.c | 32
> +---
> 1 file
sparse complains:
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c:703:6: warning: symbol
'dw_mipi_dsi_bridge_mode_set' was not declared. Should it be static?
Signed-off-by: Brian Norris
---
drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c | 6 +++---
1 file changed, 3 insertions(+), 3
o the swapping explicitly.
Some of this function could be done more easily without memcpy(), but
the unaligned "remainder" case is a little hard to do without
potentially overrunning 'tx_buf', so I just applied the same solution in
all cases (memcpy() + le32_to_cpu()).
Teste
ed to be 'len != 0', so I made that more
clear.
Tested on RK3399 with some pending refactoring patches by Nickey Yang,
to make the Rockchip DSI driver wrap this common driver.
Signed-off-by: Brian Norris
Reviewed-by: Philippe Cornu
Tested-by: Philippe Cornu
---
v2:
* remove &quo
018 01:38 AM, Brian Norris wrote:
> > This takes care of 2 TODOs in this driver, by using the common DSI
> > packet-marshalling code instead of our custom short/long write code.
> > This both saves us some duplicated code and gets us free support for
> > command types that were
this un-documented property should no longer be
useful.
Signed-off-by: Brian Norris
---
arch/arm/boot/dts/tegra20-paz00.dts | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm/boot/dts/tegra20-paz00.dts
b/arch/arm/boot/dts/tegra20-paz00.dts
index 30436969adc0..12c63b23ed5e 100644
--- a
this un-documented property should no longer be
useful.
Signed-off-by: Brian Norris
---
arch/arm64/boot/dts/nvidia/tegra132-norrin.dts | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/boot/dts/nvidia/tegra132-norrin.dts
b/arch/arm64/boot/dts/nvidia/tegra132-norrin.dts
index
this un-documented property should no longer be
useful.
Signed-off-by: Brian Norris
---
arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
b/arch/arm/boot/dts/rk3288-veyron-chromebook.dtsi
index
ed to be 'len != 0', so I made that more
clear.
Tested on RK3399 with some pending refactoring patches by Nickey Yang,
to make the Rockchip DSI driver wrap this common driver.
Signed-off-by: Brian Norris
---
Could use an extra look from folks. This looks like the correct trivial
tran
Sorry for the spam...one more thought:
On Thu, Jan 04, 2018 at 06:07:51PM -0800, Brian Norris wrote:
> On Tue, Jan 02, 2018 at 10:22:00AM +0800, Shawn Lin wrote:
> > Just use the API instead of open-coding it, no functional change
> > intended.
> >
> &g
On Thu, Jan 04, 2018 at 06:07:51PM -0800, Brian Norris wrote:
> On Tue, Jan 02, 2018 at 10:22:00AM +0800, Shawn Lin wrote:
> > Just use the API instead of open-coding it, no functional change
> > intended.
> >
> > Signed-off-by: Shawn Lin
> > ---
Other than my n
Hi,
On Tue, Jan 02, 2018 at 10:22:00AM +0800, Shawn Lin wrote:
> Just use the API instead of open-coding it, no functional change
> intended.
>
> Signed-off-by: Shawn Lin
> ---
>
> drivers/phy/rockchip/phy-rockchip-emmc.c | 21 +++--
> 1 file changed, 7 insertions(+), 14 deleti
Hi,
Trying to catch up on this thread...
On Wed, Dec 27, 2017 at 01:57:07AM +0100, Rafael J. Wysocki wrote:
> On Tuesday, December 26, 2017 2:06:47 AM CET JeffyChen wrote:
> > Hi Rafael,
> >
> > Thanks for your reply :)
> >
> > On 12/26/2017 08:11 AM, Rafael J. Wysocki wrote:
> > >> >+
> > >> >
+ Rafael to this thread
On Wed, Dec 20, 2017 at 11:19:12AM -0800, Tony Lindgren wrote:
> * Brian Norris [171219 00:50]:
> > On Wed, Aug 23, 2017 at 09:32:39AM +0800, Jeffy Chen wrote:
> >
> > Did this problem ever get resolved? To be clear, I believe the problem
> >
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
> mov
ehlcke
> 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
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 to
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
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
>&
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 threa
+ 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, but
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] Blu
I'm not sure I 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
t in drivers/usb/core/quirks.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 b
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:
> >
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 and
created/removed when
checking out different source 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
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
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, whil
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
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
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
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/
>patch/10066
+ 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.
> > A
dending to merge this, 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
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
> ---
> in
Chromebook Plus).
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 s
onfigured (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
on the "kevin&qu
+ 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 NU
esolves crashes 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(+
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 refact
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/pinc
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
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
ontroller 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 spel
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 calle
ith device
tree, 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
rence 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
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
> >>>becau
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 {
> > ...
> > .
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(-)
>
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
>
> ---
> dr
+ 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
>
> ---
> drivers/gpu/
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 vague.
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
On Wed, Nov 29, 2017 at 05:07:27PM -0800, Brian Norris wrote:
Sorry, I got the wrong $subject, will resend :(
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
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/arm6
arate from the rest of the series, since 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/roc
+ 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
> ---
> arch/arm64/boot/dts/rockchi
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
t; > +
> > + _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
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
s it 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
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 bridge
Hi Nickey,
Several people already made comments on the initial version of this
patch [1], and I don't think you've caught them all here yet. I'll
repeat a few. Not sure if I've caught them all.
[1]
https://chromium-review.googlesource.com/c/chromiumos/third_party/kernel/+/780120
On Tue, Nov 28,
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 us for removal.
Signed-off-by: Brian Norris
---
drivers/gpu/drm/bridge/synopsy
(Dropping Mark, whose Rockchip address is dead; and fixing Chris's email again)
On Mon, Nov 27, 2017 at 4:29 PM, Brian Norris wrote:
> On Thu, Oct 26, 2017 at 09:44:14AM +, Philippe CORNU wrote:
>> On 10/26/2017 06:13 AM, Archit Taneja wrote:
>> > On 10/26/2017 06:39
On Thu, Oct 26, 2017 at 09:44:14AM +, Philippe CORNU wrote:
> On 10/26/2017 06:13 AM, Archit Taneja wrote:
> > On 10/26/2017 06:39 AM, Brian Norris wrote:
> >> somebody already working on refactoring existing Rockchip code to use
> >> this?
> >
> > I d
Hi Rafael,
I'll answer some of it from my perspective, though Jeffy might have had
different ideas (and answers) when he implemented this.
On Wed, Nov 08, 2017 at 11:32:20PM +0100, Rafael J. Wysocki wrote:
> On Friday, October 27, 2017 9:26:11 AM CET Jeffy Chen wrote:
> > Move acpi wakeup code to
. Remove the code that checks if this variable is zero.
>
> Signed-off-by: Jon Hunter
Reviewed-by: Brian Norris
> ---
> drivers/mfd/cros_ec_spi.c | 25 +
> 1 file changed, 9 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/mfd/cros_ec_
size = sizeof(struct ec_host_request);
>
> + ec_spi->last_transfer_ns = ktime_get_ns();
Seems pretty reasonable to me:
Reviewed-by: Brian Norris
>
> err = cros_ec_register(ec_dev);
> if (err) {
> --
> 2.7.4
>
On Mon, Oct 30, 2017 at 8:03 PM, Lin Huang wrote:
> Document a "reset" and "assert-reset-us", it can be used for
> driver control reset property. And reuse post-power-on-delay-ms
> for deassert reset delay.
>
> Signed-off-by: Lin Huang
> ---
> Documentation/devicetree/bindings/input/hid-over-i2c
t reset delay
> - delete deassert_reset_us property
>
> drivers/hid/i2c-hid/i2c-hid.c | 61
> +++
> include/linux/platform_data/i2c-hid.h | 3 ++
> 2 files changed, 50 insertions(+), 14 deletions(-)
Reviewed-by: Brian Norris
On Thu, Nov 02, 2017 at 04:40:57PM +0100, Arnd Bergmann wrote:
> On Thu, Nov 2, 2017 at 4:23 PM, Kalle Valo wrote:
> > Brian has already fixed this, please check that:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?h=ath-next&id=20665a9076d48e9abd9a2db13d307f58f7ef66
On Mon, Oct 30, 2017 at 03:15:19PM -0500, Rob Herring wrote:
> On Mon, Oct 30, 2017 at 11:57 AM, Brian Norris
> wrote:
> > On Mon, Oct 30, 2017 at 10:49:49AM +0800, Lin Huang wrote:
> >> --- a/drivers/hid/i2c-hid/i2c-hid.c
> >> +++ b/drivers/hid/i2c-hid/i2c
On Mon, Oct 30, 2017 at 10:05:51AM +0800, Jeffy Chen wrote:
> On 10/27/2017 10:38 PM, Rob Herring wrote:
> >>+ prop = of_find_property(dn, "interrupt-names", NULL);
> >>>+ for (name = of_prop_next_string(prop, NULL); name;
> >>>+ name = of_prop_next_string(prop, nam
+ devicetree list
Hi,
On Mon, Oct 30, 2017 at 10:49:49AM +0800, Lin Huang wrote:
> some i2c hid devices have reset gpio, need to control
> it in the driver.
>
> Change-Id: I87bca954bffc7eb7b35711406f522cb3d0fc2ded
You should be removing these Gerrit ID lines from patches before sending
them to
On Sat, Oct 28, 2017 at 02:01:46PM -0400, Sinan Kaya wrote:
> I was looking for some code that can be used between OF and ACPI rather than
> duplicating the code in two different places just to extract some information
> from the platform firmware.
>
> My initial look at your code suggested it to
Hi Sinan,
I'm not sure I understand all your suggestions below.
On Thu, Oct 26, 2017 at 11:16:55AM -0400, Sinan Kaya wrote:
> On 10/26/2017 9:28 AM, Jeffy Chen wrote:
> > drivers/pci/Makefile | 2 +-
> > drivers/pci/pci-of.c | 136
> > +++
> > 2
301 - 400 of 2158 matches
Mail list logo
